Unit test examples

John Roth johnroth at ameritech.net
Sun Dec 22 08:35:26 EST 2002


"Greg Brunet" <gbrunet at nospamsempersoft.com> wrote in message
news:3e056473$0$1427$272ea4a1 at news.execpc.com...
> Thanks everyone for the recommendations.  I've downloaded Dive Into
> Python & have started looking at that & I'm trying to get a copy of
the
> draft TDDBE.  It's valuable to see how things are done on a small
scale
> so that I'm not overwhelmed trying to understand new things, and can
> learn to be more Pythonic in my thinking.
>
> One thing that I'm wondering about though, is how to handle larger
> systems - especially complex GUI applications.  The last app I
developed
> had a main screen with about 20 fields on the main form plus 4 tabs
with
> an additional 30 fields.  These all were loaded/saved to database
tables
> (with multiple parent-child relationships), about 10 of the fields had
> combobox lookups into other tables, and there were a couple of grid
> controls dynamically populated based on information entered in some of
> the key fields in the form.  Of course the application has a bunch of
> other forms to maintain other tables in the system, menu choices to
kick
> off processes, etc.  When an application grows very large, and there
are
> a lot of interdependencies between all of the controls on a form, how
do
> you handle testing all of the combinations/permutations?  It seems
even
> more overwhelming than programming it!  Thanks again,

Since you can't unit test a GUI with any significant amout of success,
you need to make it as thin as possible. There's a paper at www.c2.com,
and discussions of all this at both the extremeprogramming and
testdrivendevelopment Yahoo groups. The testdrivendevelopment
group occasionally does challenge projects, where a number of group
members write up programs to solve an interesting if trivial problem
(usual time to solution is a couple of hours.) It's a great training
mechanism.

Something else you might want to look at is Naked Objects at
www.nakedobjects.org. That's not because it does production quality
UI's, but because of the idea that if you do the underlying objects
properly, you can pretty much mechanically generate the actual UI.

>
> --
> Greg
>
>





More information about the Python-list mailing list