unit testing

[Steve Howell]

--- Steven Bethard <steven.bethard at gmail.com> wrote:
> 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/