When is unit-testing bad? [was: Re: does lack of type...]

Changjune Kim juneaftn at REMOVETHIShanmail.net
Thu Jul 3 03:40:22 CEST 2003

"Jeremy Bowers" <jerf at jerf.org> wrote in message
news:pan.2003. at jerf.org...
> On Wed, 02 Jul 2003 15:21:45 +0200, Aurélien Géron wrote:
> > I'd be interested to know about
> > projects where they automate unit tests for GUIs, but I suspect it
would be
> > just as cumbersome.
> I'm doing one right now. It's designed from the ground up by me, so it's
> testable. It almost has to be, since it's fairly complicated and Needs To
> Work.
> For the record, I've found Tkinter does *great* with this, because you
> drive the GUI without ever actually starting the event loop. It doesn't
> seem perfect but largely works, much better then it has any right to.
> wxPython doesn't work at all without an event loop, so I never did get it
> tested, which has contributed to me dropping it. ;-) (I'm gonna guess
> never entered into anybody's head when they were designing toolkits...)
> > In all those cases, I much prefer having a human being go out and do
> > unit tests manually.
> The thing is, they won't. We've got about 50 years of collective
> experience backing that up.

UnitTesting GUI is not that difficult. UnitTesting multi-threaded programs
is not that difficult. UnitTesting database programs is not that difficult.
I have experiences in all of them, of which the degree and depth might

For example, I follow a sequence(as in Christopher Alexander's style) for
TDDable GUI program:

 1. Test everything that is in P and M. Don't test V.
 2. There is no GUI framework API call in P and M.
 3. In V, there are stuffs that you can have enough confidence even without
 4. No duplication.
 5. Keep the cycle.

 1. Start from one chunk. Think about what should be shown from the
abstract level, what concepts(M) should be there. Don't use GUI API calls.
 2. You can take M and P apart. How it should be shown goes into P. What
goes into M.
 3. P uses the interfaces of V. Firstly, test P with mock-V. Put into V
only those that can be considered as "need not tests, really sure" in GUI
 4. As mock-V getting its form, implement real-V along with it.
 5. If there is anything you feel not confident pass it over to P.

These are what I get after years of experience in TDDing GUI programs.

see also(all highly recommended):
 * http://martinfowler.com/articles/separation.pdf
 * http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf
 * http://www.sdmagazine.com/documents/sdm0206b/

Best wishes,


More information about the Python-list mailing list