Newbie: Unit testing presenters?

There seems to be a quite a lot of functionality embedded in my
presenters. How does other people in this group go about testing these
automatically (ie. unit testing)? Are there any articles on this?
--

Vennlig hilsen

Syver Enstad

Syver,

> There seems to be a quite a lot of functionality embedded in my
> presenters. How does other people in this group go about testing these
> automatically (ie. unit testing)? Are there any articles on this?

I heard that a some C programmers once used the Windows 3.x event recorder
(or whatever it was called) to walk an app through some steps and then let
it run in a loop with a camcorder pointed at the monitor.  They started it
each day at quitting time and reviewed the tape the next morning to see
when/how it crashed.

The Squeak book edited by Guzdial and Rose contains a chapter on XP and it
makes reference to a similar kind of trick that can be done in Squeak.  That
chapter also suggests that simply opening/closing UI elements will catch at
least gross errors and is easy to automate.  Of course, any functionality
that you can push down into your domain classes will simplify unit testing.

Sorry that doesn't really answer your questions.  If you find any good
references, please pass them along.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> writes:

>  Of course, any
> functionality
>
> that you can push down into your domain classes will simplify unit
> testing.

Of course. But a quick look at the presenter hierarchy from Dialog and
upwards to the Presenter class seems to indicate that no direct gui
calls are made in the presenter, it's always through the view
class. My idea would be to have a non gui class that implemented the parts
of the view that the presenter relied upon. Now well, I'll have to
learn more about MVP before I am able to evaluate this properly,
There's probably a good chance that trying to emulate a view object is
just to much hassle, as the interface that Presenter and the most
common subclasses use seems to be pretty big.


> Sorry that doesn't really answer your questions.  If you find any good
>
> references, please pass them along.

I will.

--

Vennlig hilsen

Syver Enstad

Syver,

> Of course. But a quick look at the presenter hierarchy from Dialog and
> upwards to the Presenter class seems to indicate that no direct gui
> calls are made in the presenter, it's always through the view
> class. My idea would be to have a non gui class that implemented the parts
> of the view that the presenter relied upon. Now well, I'll have to
> learn more about MVP before I am able to evaluate this properly,
> There's probably a good chance that trying to emulate a view object is
> just to much hassle, as the interface that Presenter and the most
> common subclasses use seems to be pretty big.

That's an interesting idea, but, it might be easier and ultimately more
useful to have a framework for "clicking and typing" on views by name.  One
might try invoking event handlers at suitable level, or perhaps even better
post messages to the queue.  It might end up looking something like

    shellUnderTest
        leftClickInSubpresenterNamed:'something';
        type:'This would be posted as keys at random intervals';
        ...

Or, would you create a PresenterTester on the shell and send these messages
to it?  I'm a little nervous about trying to trick Windows into seeing
keyboard and mouse events, but, it would be quite useful if it could be done
safely.  OTOH, having the mouse cursor not currently where the view was
"clicked" might help to shake out some kinds of bug by emulating what
happens when the machine isn't able to keep up.  Also, we'd have to deal
with actions that bring up modal dialogs and be able to "test" them too.

Comnments?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> writes:

>it might be easier and ultimately more useful to have a framework for
>"clicking and typing" on views by name.  One might try invoking event
>handlers at suitable level, or perhaps even better post messages to
>the queue.  It might end up looking something like
>
>     shellUnderTest
>         leftClickInSubpresenterNamed:'something';
>         type:'This would be posted as keys at random intervals';
>         ...

Umm, something like an advanced SendKeys implementation?


>
> Or, would you create a PresenterTester on the shell and send these
> messages to it?

I am not sure that I follow you here. What I originally thought of was
something like this:

TestCase subclass: #MyPresenterTest

rough outline of the behaviour of MyPresenterTest

initialize the presenter with some kind of MockView instead of a real
win32 gui view.  Test that the models of the presenter and eventual
sub presenter behaves like they should when the presenter and the
MockView are manipulated.

But as I said this a bit too early for me. I'll have to understand the
MVP framework better first.

William Wake has some interesting articles on GUI testing (in Java
Swing) on his site http://xp123.com/xplor/. I'll have to check these out
before thinking any more about this.

The material on his site is also featured in the books XP installed and
XP explored by R. Jeffries and W. Wake respectively. The GUI article
is featured in XP Installed.


--

Vennlig hilsen

Syver Enstad