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

[Changjune Kim]

"Jeremy Bowers" <jerf at jerf.org> wrote in message
news:pan.2003.07.02.21.14.36.896580 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
can
> 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
that
> 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
the
> > 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
vary.

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


Principles:
 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
testing.
 4. No duplication.
 5. Keep the cycle.

Sequence:
 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
aspects.
 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/
 *
http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm

Best wishes,

June