Sb. uses the Unit Test pattern w/ GWT?

40 views
Skip to first unread message

Alexander Orlov

unread,
Sep 12, 2011, 5:17:14 AM9/12/11
to google-we...@googlegroups.com
I've tried it and found that the GWT startup or re-compilation time wasn't shortened which was the primary reason I've tried it.

Has sb. gained real production advantages using GWT's JUnit?

Thomas Broyer

unread,
Sep 12, 2011, 6:33:20 AM9/12/11
to google-we...@googlegroups.com
What do you mean by "GWT's JUnit"? (and actually how do you expect it to shorten startup or re-compilation time?)

Unit-testing is about software quality.
The most important gains are in the long run, because a set of automated tests that can be replayed at any time will ensure you don't have regressions.

With GWT, you should try as hard as possible to use "plain JUnit" (or TestNG or whatever) tests vs. GWTTestCase, because the former are much faster; and that's one of the main goals of using MVP (by mocking your view, you no longer need a GWTTestCase to test your "presenter" logic).
This is also where you'll have the most important productivity gains: writing unit tests for your presenters allows you to develop in short iterations, without the need to even start up the DevMode. You'd use the DevMode either early on to design your view, and/or later on to do some additional manual testing (and actually test your view, rather than your presenter).

Alexander Orlov

unread,
Sep 12, 2011, 6:42:52 AM9/12/11
to google-we...@googlegroups.com
On Monday, September 12, 2011 12:33:20 PM UTC+2, Thomas Broyer wrote:
What do you mean by "GWT's JUnit"? (and actually how do you expect it to shorten startup or re-compilation time?)

I mean GWT's GWTTestCase extending JUnit that's not redering any UI. Therefore the dev mode re-compilation time could be shortened (must not but could). 
 

Unit-testing is about software quality.
The most important gains are in the long run, because a set of automated tests that can be replayed at any time will ensure you don't have regressions.

For me JUnit is also about TDD. Avoiding regressions is another thing...
 
With GWT, you should try as hard as possible to use "plain JUnit" (or TestNG or whatever) tests vs. GWTTestCase, because the former are much faster; and that's one of the main goals of using MVP (by mocking your view, you no longer need a GWTTestCase to test your "presenter" logic).

I've hoped for this kind of tips.
 
This is also where you'll have the most important productivity gains: writing unit tests for your presenters allows you to develop in short iterations, without the need to even start up the DevMode. You'd use the DevMode either early on to design your view, and/or later on to do some additional manual testing (and actually test your view, rather than your presenter).

 ...and this kind. I guess, I'll give (this time "plain") JUnit another chance.

Raphaël Brugier

unread,
Sep 13, 2011, 9:55:55 AM9/13/11
to google-we...@googlegroups.com
Google I/O 2010 and 2011 gwt session are also definitely a must see If you want to learn how to test your gwt code

Gael Lazzari

unread,
Sep 13, 2011, 10:17:26 AM9/13/11
to google-we...@googlegroups.com
I don't like MVP pattern in GWT, because it envolves useless boilerplate code just to be able to run "plain JUnit" test, without the slow GWTTestCase. 

The gwt-test-utils project (http://code.google.com/p/gwt-test-utils/) is a good alternative since it also to run GWT client code in JUnit tests without GWTTestCase. And it's way more faster (it was designed to make GWT compliant with TDD.

It also is more complete that "just" testing your presenter : it enables you to test your bindings and can even simulate any web browser event (click, blur, change...)

Reply all
Reply to author
Forward
0 new messages