On Tue, Nov 24, 2009 at 2:02 PM, Serdar Tumgoren <zstumgo...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
