| |
comp.lang.python |
--- Steven Bethard <steven.beth...@gmail.com> wrote: > http://codespeak.net/py/dist/test.html > I've heard good things about it, but haven't gotten > def test_answer(): Nope, I haven't. I'm a tremendous advocate of unit I have slowly introduced unit testing into my own work 1) For flat-out failures, we just fail with a 2) We don't use assertions very often, but rather 3)We have a little trickery to override imports, 4) We have quite a few mock-ish objects, mainly ___________________________________________________________________________ _________Pinpoint customers who are looking for what you sell.
> around to trying it
> yet. Here's a two-line test suite from the page
> above:
> assert 42 == 43
testing, but I've never felt compelled to try out
other libraries, because I work mostly on private code
now, so the
following-standard-practices-to-benefit-from-familiarity
argument doesn't carry much weight with me, and also
because I find it easy enough to do things on a
roll-your-own basis. YMMV, of course.
environment, with some success. We don't use a 3rd
party testing framework, but here's my roll-your-own
approach:
traceback right away. We don't bother to capture
stats on how many tests failed. If one test fails,
that's enough to clue in a developer that he/she broke
something.
just diff the output files to the GOLD files. This
may eventually stop to scale, but it hasn't yet.
etc., as 99.99% of our code was never written with
unit testing in mind, but I still want to regression
test it.
relating to simulating I/O situations.
http://searchmarketing.yahoo.com/