Junit 4 support

[dankurka]

Originally reported on Google Code with ID 1683

When Issue 168 gets resolved then we could upgrade Junit support from the 3
series to Junit 4.

Reported by hugo.a.garcia on 2007-09-21 19:05:56

[dankurka]

Reported by bruce+personal@google.com on 2008-10-21 21:58:17

• Labels removed: priority-medium

[dankurka]

Reported by acc%google.com@gtempaccount.com on 2008-12-12 07:00:48

• Labels added: Type-Enhancement, Category-Build
• Labels removed: Type-Defect

[dankurka]

Reported by scottb+legacy@google.com on 2008-12-15 15:39:00

• Labels added: Category-Other
• Labels removed: Category-Build

[dankurka]

Reported by scottb+legacy@google.com on 2009-03-10 18:16:59

• Labels added: Category-JUnit
• Labels removed: Category-Other

[dankurka]

Ok, so now that it seems the issue has been fixed, when should we expect JUnit 4
support? Thanks. 

Reported by hanriseldon on 2009-08-04 13:08:04

[dankurka]

Reported by scottb+legacy@google.com on 2009-08-04 16:05:03

[dankurka]

Shouldn't this be possible with the new GWTTestCases that uses HtmlUnit?

Reported by arthur.kalm on 2009-11-17 14:08:48

[dankurka]

Just an idea: can't we make it test framework independent?
Spring does something similar from 2.5. (see manual chapter 9)...

Personally: I don't like JUnit, use testNG whenever possible.

Reported by post2edbras on 2009-11-17 14:20:42

[dankurka]

Yeah, I would prefer using TestNG as well, but I guess the question is, does the new
GWTTestCase allow you to 
use any test framework?

Reported by arthur.kalm on 2009-11-17 14:25:25

[dankurka]

This is probably obvious and maybe backseat driving, but it seems to me that the real
issue is that com.google.gwt.user.client classes cannot be 
instantiated outside a GWT context. If you could do "new com.google.gwt.user.client.ui.Button()"
from a POJO test case, you could use any testing 
framework you wish and tests would run orders of magnitude faster.

Is this an avenue that anyone is interested in exploring further?

The problem with these classes is the JSNI methods, especially static JSNI methods.
As GWT currently works, these methods cannot be replaced by 
stubs in a testing context.

From a Java perspective, it is possible to fix this without breaking existing clients.
This can be done replacing the implementation of e.g. 
com.google.gwt.user.client.DOM methods with calls to an interface which by default
is implemented just like the current DOM class.

I have been able to make this change sufficiently to instantiate the StockWatcher sample
application in a plain Java context. But I have 
insufficient knowledge of JSNI to understand what I need to do to make it work or indeed
to know if it is possible to get it to work.

Is it worth pursuing standalone execution of GWT code any further?

Reported by jhannes on 2009-11-20 23:23:29

[dankurka]

Hi guys, just wanna make me sure: Is there no way to use JUnit 4 in GWT still?

Reported by jana.lukesova on 2010-02-08 13:33:10

[dankurka]

JUnit 4 will happily run JUnit 3 tests (including GWTTestCase), so you can mix 
GWTTestCase and JUnit 4 "pure Java" unit tests. Does that answer your question?

Reported by t.broyer on 2010-02-08 15:47:03

[dankurka]

2 t.broyer: not really, but helped me little bit as I am newbie, thank you

Reported by jana.lukesova on 2010-02-09 21:19:41

[dankurka]

Might be relevant issue: 4615,
http://code.google.com/p/google-web-toolkit/issues/detail?id=4615

Reported by post2edbras on 2010-02-11 10:11:34

[dankurka]

Is Junit4 support going to happen?

Reported by philwillemann@yahoo.com on 2010-03-31 15:20:48

[dankurka]

We would be very happy to see support for JUnit 4.

We tried using JUnit 3(GWTTestCase) for our 'client' code and JUnit 4 for our 
'shared'/'server' - part. However some of our 'client' code naturally depends on 
parts of 'shared', which is also reflected by the test structure. The JUnit 3 tests

will fail because GWT is not able to handle the JUnit 4 imports and hence produces

compile errors.

The only way I see by now, is to completely stick to JUnit 3 or to here from you, 
that JUnit 4 is coming. And of course when it is...

Reported by horst.andreas82 on 2010-04-13 17:25:46

[dankurka]

It seems some work as already been done by Ian Petersen:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/966e3b159ce1a7b1/b8d90123b64ccc82?#b8d90123b64ccc82

Reported by frederic.conrotte on 2010-05-19 08:17:47

[dankurka]

I'm Ian Petersen, and that's old, gnarly code.  I doubt it even works with recent GWT
because it relies on the metadata system that predates annotation support, and I
expect that's been ripped out of GWT by now.  Feel free to use that jar as a starting
point, though.

Ian

Reported by ispeters on 2010-05-19 15:53:45

[dankurka]

Even if it works (or did work), I don't think that it is the best strategy. Rewriting
(large) parts of JUnit is surely too intrusive. A dedicated TestRunner (that can fork
when needed) seems to be the right lightweight solution to me.

Reported by mguillemot@yahoo.fr on 2010-05-20 07:20:15

[dankurka]

Is the JUnit 4.0 supported for GWT 2.1?

Reported by vaishusharma on 2010-12-30 12:08:41

[dankurka]

Reported by rjrjr@google.com on 2011-01-13 03:09:43

• Labels added: Type-Feature
• Labels removed: Type-Enhancement

[dankurka]

2007 ... 2011 no progress on unit testing ? 

I just followed the decent google blog on how important unittesting is for Google and
how it is part of the company DNA ...

I need to test a few non GUI things (interactions with the GWT XML implementation)
and for that I need to extend the GWT TestCase ... can't I somehow use some mocking
to achieve the same without the long startup time for the test ?

Reported by david.nouls on 2011-04-11 13:55:18

[dankurka]

@David: if you use the (new) IsWidget interface you might not need to test it as gwt-test
case.

Everywhere were possible I use the IsWidget interface instead of the Widget class and
Mock out my Panel's where IsWidget is converted to Widget.
I can test a whole lot more now without the need for the GWTTestCase.

I hope IsWidget will be get full support in the framework in the future, see also issue
6112 (http://code.google.com/p/google-web-toolkit/issues/detail?id=6113) 

Reported by post2edbras on 2011-06-07 11:38:44

[dankurka]

For the developers interested: I wrote a little forum post about testing with the IsWidget
interface that makes testing easier (without the need for GWTTestCase):
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/87030a9ae66fe012

Reported by post2edbras on 2011-06-09 14:18:53

[dankurka]

Isn´t it done yet?

Reported by hablutzel1 on 2011-08-15 15:06:29

[dankurka]

Reported by rjrjr@google.com on 2011-10-05 00:08:01

• Status changed: PatchesWelcome

[dankurka]

Running a GWTTestCase using JUnit 4 works now (kinda). I recognizes the @test annotation,
but funny enough, it ignore the @ignore one.

Perhaps this is a smaller problem than the good GWT folks realize?

Reported by pas256 on 2011-11-16 05:41:31

[dankurka]

So what is the *actual* issue that prevents using JUnit 4.x??  This is unclear to me
from these posts.  Also, has the issue been resolved - i.e. is JUnit 4 supported now?

Reported by meturner64@comcast.net on 2012-03-16 15:09:20

[dankurka]

The actual issue is convincing someone that it's more important than other things they
could work on. Our team is quite small these days, and personally, I would rank JDK
7 support and better browser support as more important, particularly when JUnit 3.x
works fine like it always has. As with any open source project, if someone really feels
strongly about it, they're welcome to dive in.

Reported by skybrian@google.com on 2012-03-16 18:14:09

[dankurka]

GWT unit tests can be run with JUnit 4 due to backward compatibility with JUnit3.
This way GWT unit-tests of the project may be in JUnit3-style.
And non-GWT unit-tests may use all the power of JUnit4.

Reported by alexander_prudnikov@xyratex.com on 2012-03-16 18:22:32

[dankurka]

Reported by skybrian@google.com on 2012-11-06 06:41:28

• Labels added: Category-Testing
• Labels removed: Category-JUnit

[dankurka]

To me as a newbie to GWT (but doing Java development for a long time) it seems that
Google is no longer supporting GWT. Why? Because testing is a very, very important
thing and JUnit 4 (released SEVEN years ago) is still not supported. Code using GWT
is nearly untestable (without hacks). My personal solution - after a week of learning
GWT - is to stop learning GWT and evaluating alternatives (yes, they exist). A good
architecture and readable and manageable code is very important to me.

I'm writing this because it seems that no one of Google's GWT team is interested in
this issue. In SIX years t's still not resolved.

Reported by marcus.fihlon on 2013-03-17 15:26:53

[dankurka]

I'd be interested in the alternatives, would you list please, thanks

Reported by peter.ondruska on 2013-03-17 15:30:29

[dankurka]

For many reasons (including: GWTTestCase are sloooow), people abstract anything that'd
require a GWTTestCase so they can use tests that runs in the JVM (JUnit4, TestNG or
whatever) and are thus much faster. This includes using MVP for instance.

Other than that, the support for JUnit in GWT involves a huge machinery (really, have
a look at GWTTestCase source and start delving into its dependencies: JUnitShell, etc.),
and porting it to a JUnit4 Runner is not that easy, because you'd also want other JUnit4
features to be supported (e.g. rules or test ordering). And we'd still have to support
the JUnit3-way of doing things 'cause we don't want to break everyone's tests; that
would then require a huge refactoring of the GWTTestCase internals to make them work
with both GWTTestCase (JUnit3-style) and an hypothetical @RunWith(GWTJUnitRunner.class).

Given the limited scope of things you can do in a GWTTestCase, JUnit3 is not really
an obstacle in practice; so you're basically asking that someone spends days (if not
weeks) reworking the machinery for a relatively limited gain in the end.

Reported by t.broyer on 2013-03-17 17:00:38

[dankurka]

> I'd be interested in the alternatives, would you list please, thanks
Read post #24 above...

It's all about priorities and the dev team have better things to do, and currently
there are better alternatives then using GWTTestCase. It's not the preffered way of
testing. You should mock the dom part (see #24) and unit test all none-presentation
parts..

Reported by post2edbras on 2013-03-17 19:19:25

[dankurka]

Actually, GWTTestCase is used extensively in GWT's own tests and we're putting some
effort into cleaning it up (making it faster, more reliable, and have better errors).
See the changelog and gwt-reviews for details. It's a mess, so this takes time.

We've talked about JUnit 4 but disagree on whether it's important; certainly it's not
necessary for our own testing.

Reported by skybrian@google.com on 2013-03-17 20:39:52

[dankurka]

> Actually, GWTTestCase is used extensively in GWT's own tests 
I understand that, as a the maker of "Element" code, tightly coupled to the DOM.

However, as a "user" (developer) of this tested code, further away from the DOM, with
a correctly setup of your GWT code, you will almost not need GWTTestcase, and can do
mostly with old fashion unit tests. 

Reported by post2edbras on 2013-03-18 08:07:35

[dankurka]

Do not just assume all code can be expressed in MVP and somehow get rid of
client side test automatition

I have quite a lot of code that has double implementations for performance
and technical reasons and it is imperrative that I can unittest this with a
GWTTestCase.

As an example I have a org.w3c.dom emulation in my project that I unittest
to make sure that it is compatible with the real dom implementation in the
JRE.
This particular example would not be needed if GWT somehow would have
offered a real DOM emulation using the official org.w3c APIs, but I have
lots of other cases where I have client specific code that needs to be
tested with a GWT Unit Test.

David

Reported by david.nouls on 2013-03-18 10:47:48

[dankurka]

> Do not just assume all code can be expressed in MVP and 
>  somehow get rid of client side test automatition

You are absolutely right, but please read the post referenced in #25, it explains that
no all can be tested in MVP, and what alteratives can be used to test a lot "more"
(not all of course, but in most cases enough)..

Reported by post2edbras on 2013-03-18 12:00:59

[dankurka]

I read and even comments on links posted in this thread (I don't see one in #25). 

But it does not apply to many of my testcases because the code is not Widget based.
All the rest of my code is using MVP and there I have used a lot of painful tricks
to get them Widget-less. But some things need to be automatically tested in the browser
because we rely on browser or client only APIs (as in my XML org.w3c.document support).

Reported by david.nouls on 2013-03-19 08:20:12

[foal]

Bump. Maybe JUnit 5?