Re: TDD and database GUIs

On Monday, January 27, 2003, at 4:58:19 AM, Patrick O'Beirne wrote:

> I take it that TDD means Test Driven Development and not Top-Down 
> Development which is driven by prior detailed design.

Yes, here at least, TDD generally means Test-Driven Design.

Top-Down Development and prior detailed design are two separate things as
far as I know.

> 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.

Well, um. If that's the approach we take to development, it will be hard to
to TDD, since there's no logic until late on. I'd be more inclined to work
the app from the viewpoint of the logic and the data structure, and less
from randomly creating (throwing up is a good phrase) a table and a form.

> 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?

I'm not aware of any database-related ones, or GUI ones in the sense that
you probably mean. There's a little GUI testing material in my Adventures
in C# series, but not much. And Phlip has created a new yahoo group,
TestFirstUserInterfaces.
(http://groups.yahoo.com/group/TestFirstUserInterfaces )

> 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.

Yes. But that isn't testing, is it? Whether testing such things is valuable
is up to you and your experience. If problems don't wind up in production
very often, then whatever you're doing now is probably good enough. I write
tests for GUI function, but do not generally write them for GUI appearance.
Others write tests for appearance and for function.

> 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.

I test reports that way all the time. Many of us do.

Let me tell you a story of a client who had two separate implementations of
a report which they always compared manually before shipping. Except for
the day they shipped it to the board of directors ...

On the other hand, if you aren't having problems and your reports don't go
to anyone who can kill you ... you're probably OK where you are.

> 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.

Yes. That's how you do it.

> But such  work is probably better done 
> by separate QA testers than by the developer, I imagine.

I think the word "imagine" was well chosen. It would depend, to my taste,
on how quickly the QA people turned the tests around. I don't like waiting
weeks -- even days -- to find out I've made a mistake. And it would depend
on how good they are -- I don't like shipping bad code to the end users,
and it makes no sense to blame QA people for my bug. And it would depend on
my sense of pride in my work -- I don't like other people to know how many
bugs I create, so I try to take them out before I send the code along.

That said, if I had some trained folks to adjust the tests real fast, I'd
sure use them. If I didn't ... I'd try to figure out some way to make the
test adjustment easy and automatic, since I have this problem with being
embarrassed by shipping defects.

> 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.

All this aside, it really comes down to what works for you. If you're
satisfied with reliability in these areas, then I'd say to invest
elsewhere.

In the database area, I try to focus on the logic and the shape of the
data, and to go to tables very late in the process. But I don't do enough
database stuff lately to be able to offer really great advice beyond that.
Let's see if other folks chime in ...

Ron Jeffries
www.XProgramming.com
The Great and Powerful Oz has spoken.


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/