[TIP] real world testing

Ryan Freckleton ryan.freckleton at gmail.com
Thu Jul 2 21:55:51 PDT 2009


On Thu, Jul 2, 2009 at 8:02 AM, Matthew Wilson<matt at tplus1.com> wrote:
> Hi Noah,
>
> On Thu, Jul 2, 2009 at 5:37 AM, Noah Gift<noah.gift at gmail.com> wrote:
>> I keep going back and forth in swings on very strict 100% code coverage vs
>> solving problems quickly under 2 day deadlines.  I think so far the 2 day
>> deadline approach wins.  My gut tells me that there is some new theory of
>> testing that is a bit more real world then the testing Nazi
>> approach.....especially in things like web development or film production.
>>  Comments?

I think of it as more of a continuum. Even when I'm going fully TDD,
requiring failing tests, I don't always end up with 100% coverage.
Testing doesn't have to be a switch you turn off or on, it can be a
knob you tune up or down depending on the situation.

Something else to think about -- when you're hacking something
together in two days, how much are you relying on pre-tested
components that you either wrote previously or someone else wrote?

> I think about this a lot.  I find I get the best ROI on writing tests
> when any of these are true:
>
> * The need for quality is more important than getting it done quickly.
> * I don't trust myself to get it right the first time.
> * I'm not sure exactly how to solve the puzzle yet.  Writing tests
> clarifies what I need.
> * I'm happy with an interface but I want to improve the implementation.
> * I'm fixing a bug that is not fast to reproduce manually.

Maybe I've drank too much testing koolaid (mmm, strawberry!) But I
find I develop *faster* when I write tests as I'm going along. Much
faster than my coworkers who don't write tests as they develop.

good wishes,
=====
--Ryan E. Freckleton



More information about the testing-in-python mailing list