Code correctness, and testing strategies

D'Arcy J.M. Cain darcy at druid.net
Sat May 24 16:34:14 EDT 2008


On Sat, 24 May 2008 17:51:23 +0200
David <wizzardx at gmail.com> wrote:
> Basically, with TDD you write the tests first, then the code which
> passes/fails the tests as appropriate. However, as you're writing the
> code you will also think of a lot of corner cases you should also
> handle. The natural way to do this is to add them to the code first.
> But with TDD you have to first write a test for the corner case, even
> if setting up test code for it is very complicated. So, you have these
> options:
> 
> - Take as much time as needed to put a complicated test case in place.

Absolutely.  You may think that it is slowing you down but I can assure
you that in the long run you are saving yourself time.

> - Don't add corner case to your code because you can't (don't have
> time to) write a test for it.

If you don't have time to write complete, working, tested code then you
have a problem with your boss/client, not your methodology.

> - Add the corner case handling to the code first, and try to add a
> test later if you have time for it.

Never!  It won't happen.

> Having to write tests for all code takes time. Instead of eg: 10 hours
> coding and say 1/2 an hour manual testing, you spend eg: 2-3 hours
> writing all the tests, and 10 on the code.

In conventional development, 10 hours of code requires 90 hours of
testing, debugging and maintenance.  Under TDD (and agile in general)
you spend 20 hours testing and coding.  That's the real economics if
you want to deliver a good product.

> I think that automated tests can be very valuable for maintainability,
> making sure that you or other devs don't break something down the
> line. But these benefits must be worth the time (and general
> inconvenience) spent on adding/maintaining the tests.

I can assure you from experience that it always is worth the time.

> If I did start doing some kind of TDD, it would be more of the 'smoke
> test' variety. Call all of the functions with various parameters, test
> some common scenarios, all the 'low hanging fruit'. But don't spend a
> lot of time trying to test all possible scenarios and corner cases,
> 100% coverage, etc, unless I have enough time for it.

Penny wise, pound foolish.  Spend the time now or spend the time later
after your client complains.

> I'm going to read more on the subject (thanks to Ben for the link).
> Maybe I have some misconceptions.

Perhaps just lack of experience.  Read up on actual case studies.

-- 
D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.



More information about the Python-list mailing list