unit testing

S

Steve Howell

--- Steven Bethard said:
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/
 
S

Steven Bethard

Steve said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,787
Messages
2,569,631
Members
45,338
Latest member
41Pearline46

Latest Threads

Top