TDD and database GUIs

Patrick O'Beirne <[email protected]> Mon, 27 Jan 2003 09:58:19 +0000
Newsgroups gmane.comp.programming.extreme-programming.adoption
Message-ID <[email protected]>
I take it that TDD means Test Driven Development and not Top-Down 
Development which is driven by prior detailed design.

My question is this: my work normally involves routine corporate database 
stuff.  Create a table, throw up a data entry and a search form, add some 
menus or buttons to print reports that analyse the data in different ways. 
As time goes on, import/export data, batch transaction processing, etc etc.

Now the kind of examples I see in test-first programming are simple 
algorithmic code such as list handling.  That's fine for examples, it needs 
something that can be explained in a few minutes.

Has anybody got examples of this technique applied to database and GUI apps?

In an example quoted earlier, if a field format is wrong (too small, needs 
a currency symbol, whatever) the first look at it will tell you and the fix 
is done the next time that resource or edit field is edited.  If the wrong 
data is there, then it depends on how visually obvious that is.  But a GUI 
is only visible to the user, not introspectively to the app.

If a printout is wrong, that can only be seen visually, the program can't 
see its own print output. I could of course rewrite the entire report 
generation system to permit printing to text files and then put in some add 
on to scan the files and compare before- and after- change output sets, 
ignoring non-significant changes such as timestamps.  You can guess how 
likely that is.

The difficulty with test sets is that it means keeping a test database and 
input and output sets in a consistent state even though it's in constant 
revision as the app expands. Nothing unusual in that problem, that's common 
to all management of test data sets. But such  work is probably better done 
by separate QA testers than by the developer, I imagine.

Maybe some people on this list have described techniques that they have had 
some success with, even though they don't address all the problems, just 
the easily solved ones?  By "easily" of course I mean what looks easy in 
retrospect, when solved.

TIA

Patrick


To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/