[TIP] Testing Hierarchy

Noah Gift noah.gift at gmail.com
Mon Jul 20 23:22:37 PDT 2009

On Mon, Jul 20, 2009 at 10:56 PM, Douglas Philips <dgou at mac.com> wrote:

> On or about 2009 Jul 20, at 11:52 PM, C. Titus Brown indited:
> > 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.
> IIRC, in "Test-driven Development" Kent Beck describes tests as
> transmuting fear into boredom.
> "Fear" being the fear of changing the code without breaking something.
> The suspiciousness here seems to be a similar thing. I like both:
> Tests transmute fear/suspicion into boredom.
> > Oh, and as an addendum, whenever you're not suspicious of your
> > software,
> > you're wrong.
> So true, and so easy to forget.
> > 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.
> I'd love to redefine developer such that someone writing code without
> tests is not a developer. :)

I agree with most of the really good points in this thread, which I forget
if I hijacked or not :), but the elephant in the room is you CAN actually
write ok code without testing if some of these factors are in place such as:

1.  The problem is trivial.
2.  The developer is used to writing good code, such as code that is
actually testable, ironically.
3.  The developer is really, really, really good (yes non testing coding
ninjas exist).
4.  The code doesn't need to be production quality.
5.  It is compiled and written with some uber dev tool like Eclipse or
XCode and isn't too complex.
6.  Your writing a prototype based on well tested libraries.
7.  The people you work for don't care you write shitty code and you don't
realize you write shitty code, and shitty code kind of works for the year
you work at the company before you quit.
8.  You might get sucked into a job where you will get fired if you test
your code....believe it or not, it could happen to you!

The downside of not testing code is often when the problem doesn't fit one
of these "dirty secrets", and someone gets into what Titus calls the lack of
testing "death spiral".  This is when you rolled out a web application that
a company depends on and it is straight up html print statements and if/else
to the moon, with some triple quoted javascript print statements to boot.
 If you created the implosion yourself, or watched it, then you probably get
spooked about not writing tests...if you can still get work as a developer.

The problem is non testers/beginning developers, old school C++ CTO's, non
developers, and even expert old school developers, etc, intuitively know you
can "ride your code dirty" and get away with it... a lot of the time.  I
think the real world testing spirit acknowledges this elephant, and tries to
adapt for it....thus the question.  I would love to see a treatment on this
subject at PyCon, in a book, etc :)

> -Doug
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/testing-in-python/attachments/20090720/faff3ef7/attachment-0001.htm 

More information about the testing-in-python mailing list