Fog Creek Software
Discussion Board

Automated Unit Testing Redux

A few days back, I posted that i was having problems coming up with a good automated unit test for a SQL data extraction script.

Well, I broke the thing down into sub-routines, and for each of those, I wrote tests:

Bad input, does it report error?
different parameter Bad input, does it report error?
Good Data, does it report success?


For a simple:

select * from table;
while (<next>) { print $_; }


I test to make sure the data is in the right order,
that it's the right total length (it's space delimited),
etc, etc. 

Is this overkill?  helpful?  In the right direction?



Matt H.
Monday, March 10, 2003

data in correct order? place a ORDER BY statement in the SQL. then you can assume it's in correct order. if you can't assume that reorder from code.but retest it :)

Monday, March 10, 2003

It really is not overkill if you feel comfortable with what you have produced. The idea of unit testing is to give you confidence that your code does what is expected. You are the one in charge of how many unit tests you should write so I would say if you feel comfortable then it is not overkill.

Ian Stallings
Monday, March 10, 2003

If you are feeling that it is overkill then you should consider automating the process further.  Testing is good full stop.  If you are finding it cumbersome then figure out a way to remove the drudge and allow you to add even more with even less time. 

The stuff I do to make sure my code is correct is overkill when things are going fine.  When they are not the fact that the problem is normally spotted before any actual 'bug' becomes visible to me using the application along with details on the peice of code that is causing problems saves sooo much time I cannot imagine not doing things this way.

You might also consider general static testers to be run over the code as well looking for common goofs.  Lint equivalents can be very useful.  I have not had much success with them myself and only run lint every couple of months because of the fact that it's output is a real pain to work through.

Colin Newell
Monday, March 10, 2003

I don't work a lot with databases so this probably doesn't apply, but...

If I control the data, I try to put choke points on where it can come in and out, and then test things like tryng to get data out of order, bad length or whatever. If these pass, I assume for the rest of the program that the data won't be that way. Maybe that is cheating though...

If I don't control the data, the tests pretty much have to be in the actual code, so I would test with bogus input and check to be sure the code fails properly. The test there is to be sure your code handles bad data, the good data should work if your first test did (of course a few tests are needed to be sure, but I don't go all out).

Generally I write a more tests for things I'm more worried about, but what they catch always suprises me too...

Robin Debreuil
Monday, March 10, 2003

Agreed with Ian Stallings.

For me, one of the lovely results of automated tests is that they reduce worry.  If you have a suite of automated tests for a routine, then you can cease worrying about whether something will break it in the future; the tests will tell you.

If these tests are completely automated, and they tell you everything you want to know, then what is there to worry about?  Congratulations!  Your code is ironclad, which is much more than most developers can claim about their code.

Brent P. Newhall
Tuesday, March 11, 2003

*  Recent Topics

*  Fog Creek Home