unit testing

[Steve Howell]

Have you tried py.test?

http://codespeak.net/py/dist/test.html

I've heard good things about it, but haven't gotten
around to trying it
yet. Here's a two-line test suite from the page
above:

def test_answer():
assert 42 == 43

Changed the subject line.

Nope, I haven't. I'm a tremendous advocate of unit
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.

I have slowly introduced unit testing into my own work
environment, with some success. We don't use a 3rd
party testing framework, but here's my roll-your-own
approach:

1) For flat-out failures, we just fail with a
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.

2) We don't use assertions very often, but rather
just diff the output files to the GOLD files. This
may eventually stop to scale, but it hasn't yet.

3)We have a little trickery to override imports,
etc., as 99.99% of our code was never written with
unit testing in mind, but I still want to regression
test it.

4) We have quite a few mock-ish objects, mainly
relating to simulating I/O situations.










____________________________________________________________________________________Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/

 

[Steven Bethard]

Changed the subject line.

Nope, I haven't. I'm a tremendous advocate of unit
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.

My view is generally that if I can get someone else to maintain parts of
my code for me, that's a good thing. ;-)

1) For flat-out failures, we just fail with a
traceback right away.

Looks like that's the -x/--exitfirst option in py.test.

2) We don't use assertions very often, but rather
just diff the output files to the GOLD files. This
may eventually stop to scale, but it hasn't yet.

I guess I don't do enough stuff with file input and file output for this
to make sense for me.

3)We have a little trickery to override imports,
etc., as 99.99% of our code was never written with
unit testing in mind, but I still want to regression
test it.

4) We have quite a few mock-ish objects, mainly
relating to simulating I/O situations.

You might look into the Python Mock module:

http://python-mock.sourceforge.net/

STeVe