Google Data

Posted by John Thomas and Markus Clermont Guiceberry is a framework to allow you to use a composition model for the services your test needs. In other words, if your test depends on certain services you can have those services "injected" into your tests using a popular dependency injection tool called Guice.

In our example we need to annotate the RPCImpl object with "@Inject" in the servlet test class and create an alternate implementation called MockStoreService to swap in at run time. Here's a code snippet that shows how:

@GuiceBerryEnv(StoreGuiceBerryEnvs.NORMAL)

public class StorePortalTest extends TestCase {

@Inject

StoreServiceImpl storeService;

public void testStorePortal() {
...
storeService.doSomething();
...
}

}

In the code snippet above, note the lines marked in bold. That's Guiceberry magic that allows us to inject a StoreServiceImpl object into the StorePortalTest class. The construction of the StoreServiceImpl is done inside a Guiceberry environment class called NormalStoreGuiceBerryEnvs (and linked to StorePortal via the StoreGuiceBerryEnvs class). To inject a mock RPCImpl into StorePortalTest we would need to create a MockStoreGuiceBerryEnvs (which would instantiate a mock StoreService) and swap that for NormalStoreGuiceBerryEnvs at run time. All we need to do is to specify the following JVM args for the test ...

JVM_ARGS="-DNormalStoreGuiceBerryEnvs=MockStoreGuiceBerryEnvs"

This is just a quick peek at how Guiceberry works. Go to the official Guiceberry website to learn more.

This will be enough to decouple the client from the rest of the system. GwtTestCase does the rest of the job on the client side. You find more details here. Don't forget to inject all possible failure scenarios through the MockStoreService.

Let's see what we found out so far:

• We know that
• • UI callbacks work correctly
  • Interaction UI - Frontend works fine
  • Expected errors are handled adequately by the UI
• We don't know whether

Although we already found out quite a lot about the UI, it is too early to be confident that the client works as expected. We need to know more about the UI to be able to answer the remaining two questions.

This is where some more traditional techniques, namely automated UI tests, enter the stage.

• Add JavaScript hooks into the page, that return the elements (JSNI is the way to go here)
• Use Selenium for UI tests (using both the hooks and the MockStoreService). All we need to do is check whether
• • the elements exist
  • all the buttons (which need to be clicked on) are clickable
  • scrollbars are added when needed

We don't need to do more work here - the GwtTestcase helped us to determine that that the "Model" and the "Controllor" work properly. All we needed to look at is the "View".

One problem we have often had with Selenium tests in the past was that people relied overly on XPath queries to retrieve the elements from webpages. Of course, when the DOM changed it caused many tests to break. One way to work around that is to introduce JavaScript hooks. They are only added when the application runs with a special "testing" flag and they directly return the elements needed.

You might wonder why this approach is any better? Well for one, we can catch problems earlier, and fix them without even looking at the tests that use them. A small and fast JsUnit test can be used to determine whether a hook is broken. If so, it is only a line of code to fix the problem.

Let's review what we have found out so far:

• We know that
• • UI callbacks work correctly
  • Interaction UI - Frontend works fine
  • Expected errors are handled adequately by the UI
  • Things are rendered appropriately
  • DOM is correct
• We don't know whether
• • Other (non-UI) components work as expected