By the way, Ext GWT provides a nice MVC framework for GWT.

private NoteServiceAsync noteServiceMock = createMock(NoteServiceAsync.class);

is invoking GWT.create() automagically and failing as GWT.create() can only be called from within a GWTTestCase. I tried extending the NoteEditorControllerTest from GWTTestCase with all the setup changes, but then all tests started failing – that could be a setup issue.

To cut a long story short, can someone please try this with GWT 1.5.2?

I also had to modify the POM slightly to include the windows-platform jars and libraries – Minor change mostly.

com.google.gwt
gwt-dev
${gwtVersion}
${platform}-libs
zip
provided

com.google.gwt
gwt-dev
${gwtVersion}
${platform}
provided

You can possibly name the zip archive to mvc-demo.tgz.zip, so it can be uploaded.
The "tgz" in the name will let folks know this is a "tgz" archive. You can possibly put an instruction to "rename" the archive.

The second thing is the "logic in view" point. I'd aim to keep the logic in views to an absolute minimum. There can be multiple controllers that keep application state and UI state for example. As long as you don't put it in the view I do not have a very strong opinion on where the controller logic should go exactly. Arguably there is no guarantee that someController.hideSomeViewElement() actually hides the view if you haven't tested that, so that is where UI testing comes in.

If you're using mocks for the view elements (remember that you cannot mock the actual classes, so you have to extract an interface), you can make sure that the view altering methods are actually called, so you do not have to test every scenario. Also you can be confident that refactoring doesn't break the UI behavior even if you're not doing the acceptance test.

If you want more in depth examples you could go look for Rob van Maris' blog. (see trackbacks)

For example, imagine an application where a drop down dynamically hides some buttons. You could still fire events against those buttons, even though they don't appear on the screen – hence the unit test would still pass. If you use acceptance testing for the UI interactions (ie. via Selenium), the test would fail.

My preference is to separate any logic that exists on the view into a separate class and unit test that. For example we've recently coded a chart widget that used various coordinate systems and axis scales – all of which could be driven by unit tests. However the click interactions with the chart had to be driven by acceptance tests.

I'd be interested to see how strong you find the tests over time as well – i.e. if you are refactoring the view/controller, how easy it is to deal with broken tests.

Good to see other people trying new stuff with GWT though – and I'll try and keep up to date with your blog.

If you don't want to use a conversion layer to transform your domain objects to Dto's AND you don't want to completely decouple client from server. You're stuck with what you have now.

There are people arguing that orm annotations don't belong on your domain objects anyway, and the problem you're facing is an argument for that. On the other hand it can be very convenient, but then you can't use the same objects on the client cleanly.

The cleanest solution would be to completely split client and server, the most pragmatic (and ugly) one is to have the hibernate dependency on the client. Using xml instead of annotations is the middle ground. Let me know how it worked out for you, it'd be interesting to hear your experiences.

Do you have a suggestion for a way that I can work together with hibernate anottations, MVC and GWT ?