Testing complex Widgets without interface ?

[Ed]

I like to know how others test their logica in complex widgets.

Example: I have a Form and FormField widget and the both extend from
Composite.
They contain logic that I would love to test in a unit test which is
hard.

Of course I could split this up in a MVP pattern, but that isn't very
elegant on widget level and too cumbersome in this case.

So this makes testing very hard... and it can only be done through the
slow GWTTestCase JUnit mechanism.
If I would have a Widget interface, I could easily mock the Form and
FormField with a test implementation containing the logic that I want
to test.

I am now considering these widgets to NOT extends from Composite
anymore such that I can create them in a not-gwt environment and test
them properly.
I then let Form and FormField implement HasAWidget interface that
contains a method Widget asWidget(), in case you want the associated
widget from Form and FormField..
It's an OK solution, but still a workaround because we don't have a
Widget interface.

I am suprised that not many people talk about this problem in the
community so maybe I am just missing something :(
I noticed this issue: 5275, that is similar:
http://code.google.com/p/google-web-toolkit/issues/detail?id=5275

How do you do this?

[Stephen Haberman]

> It's an OK solution, but still a workaround because we don't have a
> Widget interface.

GWT 2.1 does have an IsWidget interface, if that is all that you need:

http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/app/place/IsWidget.html

If you need more, I've been making interfaces for each widget:

https://github.com/stephenh/gwt-mpv/tree/master/user/src/main/java/org/gwtmpv/widgets

They work great for my purposes, e.g. I can do:

IsTextBox t = newTextBox(); // will be real text box or stub text box
t.getStyle().setColor("blue");

And in a non-GWT unit test, use the stub widget/stub style to:

assertThat(t.getStyle().getColor(), is("blue"));

(Also, I commented on the bug you mentioned--I hadn't seen that before.
Thanks for the link.)

- Stephen

[Thomas Broyer]

See my answer in the issue tracker; in brief, move from a "Passive
View" pattern to a "Supervising Controller" pattern and you'll no
longer see "widgets" in your presenter.

[Thomas Broyer]

Oops, sorry, I read your post too fast and missed the point: you want
to test widgets, not an "MVP component".
Have a look at the Cell widgets' internals, they use MVP internally so
the presenter can be tested independently from the views.

[Ed]

Thanks Thomas, now worries, I understand you point/advice,
I wasn't aware of the WhyWidgetIsAClass article which is very helpful.
I just commented on it as well. I would love to hear your advice on
that?
http://code.google.com/p/google-web-toolkit/wiki/WhyWidgetIsAClass

[Ed]

I am looking in the Cell Widgets, but can't find what you mean.
Can you give me some more details like a specific Cell Widget and his
internal presenter ?

[Thomas Broyer]

Have a look at the HasDataPresenter class.
Here's what its Javadoc says:
/**
* <p>
* Presenter implementation of {@link HasData} that presents data for
various
* cell based widgets. This class contains most of the shared logic
used by
* these widgets, making it easier to test the common code.
* <p>
* <p>
* In proper MVP design, user code would interact with the presenter.
However,
* that would complicate the widget code. Instead, each widget owns
its own
* presenter and contains its own View. The widget forwards commands
through to
* the presenter, which then updates the widget via the view. This
keeps the
* user facing API simpler.
* <p>
*
* @param <T> the data type of items in the list
*/

It's instantiated in AbstractHasData, which defines the view
(AbstractHasData.View, which implements HasDataPresenter.View; it's a
nested class so as to not expose the methods of HasDataPresenter.View
on the public API of AbstractHasData)

[Ed]

Thanks, I get the idea (don't forget to sleep sometimes ;) ).

I understand that the VP mechanism makes is better unit-testable for
GWT.

But what I don't understand: why not make Widgets like the CellTable,
CelList, ... more test friendly?
I mean: such that you can initiate them in unit test not needing a GWT
environment, just like my last notes in the issue: 5275 point out:
http://code.google.com/p/google-web-toolkit/issues/detail?id=5275