> How do you test these things? This "gwt-hack" example project is horribly unmaintained, but the idea is:
http://github.com/stephenh/gwt-hack/blob/master/src/test/java/com/bizo/gwthack/client/presenters/ClientPresenterTest.java When GwtFooView is generated, so is StubFooView, which has fields like: StubTextBox name; public IsTextBox name() { return name; } So the test can grab the StubTextBox and call methods on it, like "click" or "type" or "focus", which fire dummy versions of ClickEvent, ChangeEvent, etc. The presenter handles these just as it would native events (well, as long as you're not using native event features), and then the test can observe the side effects in the stub widgets. E.g. that the textbox's getText changed, or had style=display:none set, or what not. Here is StubTextBoxBase, for example: http://github.com/stephenh/gwt-mpv/blob/master/user/src/main/java/org/gwtmpv/widgets/StubTextBoxBase.java I have admittedly added stub functionality in an ad hoc manner, so I can't promise that it acts exactly like the browser does, but the idea is to get close enough that it's good enough for unit testing. > How does the next guy know whether his event handler belongs in the > view or the controller? Well, the view is generated, so any code he puts there will be overwritten. :-) > [snip] but clicking on the header of a disclosure panel does change > the view state, so it belongs in the view. Personally, I like putting everything in the presenter so it stays testable. > Don't forget, that by mapping each widget to an interface would allow > you to bind those up with GIN and create providers for those inside > the presenter, so if for some reasons you wanted to be able to alter > the view, you could easily do it and still keep the presenter/activity > JUnit clean. Yep. :-) I don't use GIN, but I have a WidgetsProvider interface that allows the presenter to create dynamically create "newTextBox" widgets and have it be a stub/gwt version as appropriate. http://github.com/stephenh/gwt-mpv/blob/master/user/src/main/java/org/gwtmpv/widgets/GwtWidgetsProvider.java > A first awesome step to this would be to make every widget implement > an interface exposing all their public methods. I really hated > extending every control and it will become more and more of a > nightmare to maintain as the gwt codebase changes. Agreed. I've been doing this lazily, as my apps need things: http://github.com/stephenh/gwt-mpv/tree/master/user/src/main/java/org/gwtmpv/widgets > I'd like to look more at the ui:binder changes. My idea was to add an > annotation/annoatation processor to automatically codegen a new > interface of every public method. For example :-) I started out doing this: http://github.com/stephenh/interfacegen But then I wanted stubs too: http://github.com/stephenh/stubgen And finally I gave up on APT (for this problem), because I don't want to have to code the SomeView class at all. All of the XxxView artifacts are derivable from the `ui.xml` file, so why maintain any of it by hand? Given that the APT API only supports Java classes, I had to fail over to a standard Java program that parses all of the `ui.xml` files in a project. However, given custom builders in Eclipse (which I need to do a write up of), I've found this approach to be just as nice (it runs automatically on save) as APT. > I would LOVE LOVE LOVE for every gwt object that extends UIObject to > implement a specific interface and would be more than happy to > implement this. Me too. :-) I'd love to have help maintaining what I've got started. Andrew from gwt-pectin has expressed interest in them as well--either from within gwtmpv or extracting them into a gwt-widget-interfaces project. Obviously it would be best if they were in GWT proper, but I haven't seen any indication that it is likely to happen. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
