[TIP] Testing Hierarchy

C. Titus Brown ctb at msu.edu
Mon Jul 20 20:52:27 PDT 2009


On Tue, Jul 21, 2009 at 08:02:27AM +1000, Robert Collins wrote:
-> On Mon, 2009-07-20 at 11:24 -0700, Noah Gift wrote:
-> > It is very easy to say all code should have 100% unit test coverage,
-> > have integration tests, functional tests, etc.  What I haven't seen
-> > someone talk about yet, is when that is appropriate in the real world
-> > and when it isn't, and an honest assessment of the tradeoff.  I am
-> > very sold on testing code, but how much depends on the situation I am
-> > in.
-> 
-> In previous debates I've had with people about this, I've had people
-> argue that because their time is limited, they should do less or not
-> automated testing because testing is pure waste.
-> 
-> Now, I don't think that argument is being made here :). However, the
-> rebuttal to that point can provide some clues for choosing how much
-> testing is enough.
-> 
-> And my rebuttal of choice is: Testing, and automated testing
-> specifically is part of development - not a completely separate thing.
-> So the time for testing is coming from the same time allowance that lets
-> you sit in front of a function thinking 'does that do what I want'.

Exactly, and I think this is one of the tenets of agile-with-a-small-A
that I like so much: testing and development are inseparable.

I think people who worry about spending too much time on testing
generally haven't spent enough time "attacking" their system critically.
As a former full-time exploratory tester, I view my software with
extreme suspicion while writing it, and then I apply that suspicion to
testing it.  (And then I run out of time to fix all the non-serious
problems, but that's my fault.)  I think I primarily write automated
tests so that I don't have to re-do much exploratory testing.

So that's my answer to Noah: whenever you're suspicious of some part of
your software and feel the urge to do some exploratory testing, do some.
Then, when you've done the same thing twice, automate it instead of
doing it a third time.  Soon enough you'll be adding the test code
before you've even done the exploratory testing once, and then you'll
be doing TDD.  You're done when you are no longer suspicious of your
software.

Oh, and as an addendum, whenever you're not suspicious of your software,
you're wrong.

;)

More seriously, as long as you view "writing code" and "making sure your
code works" as part of the same job, you'll be fine.  Just don't let
non-developers push you around by asserting otherwise.

cheers,
--titus



More information about the testing-in-python mailing list