Unit test examples

[Changjune Kim]

"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,
>
> --
> Greg
>
>

You should make the outer presentation layer as thin as possible. When you
think it's thin enough, you can make it thinner. And you have seperate
layers like presentation, business logic, data access.

In unittesting, you don't want to test all the combinataions -- it's "unit"
testing. You can cut off the dependency chains with good design(which could
also emerge from TDD), and some unit testing techniques like Mock Objects.

I also recommend you read GUI programming patterns papers from PLOP
conferences.