[Tutor] the art of testing

[Kent Johnson]

On Tue, Nov 24, 2009 at 2:02 PM, Serdar Tumgoren <zstumgoren at gmail.com> wrote:
> Hi everyone,
> The list recently discussed the virtues of unit testing, and I was
> hoping someone could offer some high-level advice and further
> resources as I try to apply the TDD methodology.
>
> I'm trying to develop an application that regularly downloads some
> government data (in XML), parses the data and then updates a database.
> Simple enough in theory, but the problem I'm hitting is where to begin
> with tests on data that is ALL over the place.
>
> The agency in question performs little data validation, so a given
> field can have a huge range of possible inputs (e.g. - a Boolean field
> should be 0 or 1, but might be blank, have a negative number or even
> strings like the word 'None').
>
> In such a case, should I be writing test cases for *expected* inputs
> and then coding the the parser portion of my program to handle the
> myriad of possible "bad" data?

Yes. The parser needs to handle the bad data in some appropriate way,
unless you are filtering out the bad data before it reaches the
parser. The tests should cover the range of expected inputs, both good
and bad data. If you want to test the parser, you should write tests
that ensure that it behaves appropriately for the full range of
expected data. So your tests should include the full range of good
data and some sample bad data.

The book "Pragmatic Unit Testing" has a lot of guidelines about what
to test. The examples are in Java (or C#) but JUnit and Python's
unittest are pretty similar and the ideas certainly apply to any
language.

Kent