Isomorphic WebDriver and Code Coverage

[tece321]

We are using the Isomorphic WebDriver and JUnit Test to construct a regression environment for our Client UI which is based on SmartGWT 5.x release. In fact we consulted with you to set up the environment.

The issue we are facing now is how to collect Code Coverage, line and branch etc., where the Client UI code is a black box being exercised through the WebDriver.

We have looked at EclEMMA in eclipse and don't see how it can be used to instrument the Client UI, while running independent JUnit tests. We compile the Client UI, and either run it under Tomcat, or in eclipse which launches the server, and then run our tests with Firefox using a virtual frame buffer.

How do you recommend collecting Client UI code coverage in such an environment? Is it possible to also collect code coverage metrics on the Server side too, and if so how can this be achieved?

Sorry this is such a general question, and I see there have been other similar threads from 2012 in the Forum, but these were before you supported the WebDriver methodology (I believe).

Thanks

[Isomorphic]

To get the simple one out of the way: the server-side code is a normal Java environment, so any ordinary Java coverage tool you want should work.

As far as client-side coverage, EMMA / EclEMMA is a JVM-based approach, so it could only possibly work in GWT's Development Mode.

Not only is setting up a CI environment that incorporates GWT Development Mode a tricky problem, but the traditional JVM-based GWT Development Mode is being phased out in favor of SuperDevMode. So we wouldn't recommend starting down this path.

With SuperDevMode, code coverage approaches will presumably be based on JavaScript. Searching around, we haven't seen a clear indication of the direction the GWT team intends to take here in terms of recommending tools (you could always try asking).

Certainly, there are lots of JavaScript code coverage tools available, and you could try running them with the GWT-generated code, turning off obfuscation so that the results are easier to interpret. We can't give you a clear indication of the effort involved in this path, but a couple of warnings:

1. whatever you produce may be obsoleted by something the GWT team adds to SuperDevMode in the near future

2. GWT-generated JavaScript code is unusual in many ways, and code coverage tools may make assumptions about code organization that won't work well when dealing with what GWT generates

[Isomorphic]

Ah, we've just located the relevant GWT issue.

If you take a look, the good news is that it's a recognized problem with some action being taken. The bad news is that they are obviously very early in addressing the need.

[tece321]

Ah, we've just located the relevant GWT issue.

If you take a look, the good news is that it's a recognized problem with some action being taken. The bad news is that they are obviously very early in addressing the need.

Thanks for the advice. We will monitor the developments in GWT with SuperDevMode for code coverage. Based on your advice we will halt the effort to make it work in Development Mode.

If you become aware of developments with Code Coverage in SuperDevMode it would be nice to post a comment on this or a similar thread for your user base.