Posts tagged ‘GWT’

June 29, 2011

Eclipse: Running all JUnit tests at once

by Stefan

When developing test driven it is essential to be able to run all existing unit tests over and over again as fast as possible. When the application gets larger the natural way to modularize is to distribute the code among multiple projects. I am not aware of tooling that ships with Eclipse and that allows you to run all JUnit tests based on a multi-project selection or on a selected working set.

I’ve used several workarounds in the past (Ant script, TestSuites, Maven build), but none was really satisfying. I recently stumbled upon the ClassPathSuite by Johannes Link which offers exactly what I was looking for. The library internally scans the classpath for classes with JUnit4 annotated methods and then executes all found tests. Sounds simple. This classpath-based solution also has the advantage that any Eclipse classpath container can be used so this works with OSGi-based bundles as well as with Maven projects, for instance.

Setup a ClassPathSuite test project

All you need to do is to create a new project and add a single class:

import org.junit.extensions.cpsuite.ClasspathSuite;
import org.junit.runner.RunWith;

@RunWith(ClasspathSuite.class)
public class RunAllTests {
}

If you’re with Maven, the library can be referenced like this (if not follow this link):

 <repositories>
    <repository>
      <id>http://maven.xwiki.org</id>
      <url>http://maven.xwiki.org/externals</url>
    </repository>
  </repositories>
  
  <dependencies>
    <dependency>
      <groupId>cpsuite</groupId>
      <artifactId>cpsuite</artifactId>
      <version>1.2.5</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

read more »

Advertisements
June 22, 2011

Running integration tests against a GWT RequestFactory based back-end

by Stefan

Update 20.07.2011: Added post.releaseConnection() class to HttpPostTransport

If your app uses GWT’s RequestFactory capabilities, a well-defined external interface to your back-end is automatically exposed. The definition is provided using the RequestContext interfaces that are mapped to a service running in the back-end. Example:

Back-end service:

package cleancodematters.server;

import cleancodematters.server.domain.Pizza;

public interface PizzaDao {
  void save( Pizza pizza );
  Pizza findById( Long id );
}

RequestFactory with RequestContext (see the first tutorial for the full code):

package cleancodematters.client;

import cleancodematters.server.DaoLocator;
import cleancodematters.server.PizzaDao;

import com.google.web.bindery.requestfactory.shared.Request;
import com.google.web.bindery.requestfactory.shared.RequestContext;
import com.google.web.bindery.requestfactory.shared.RequestFactory;
import com.google.web.bindery.requestfactory.shared.Service;

public interface PizzaRequestFactory extends RequestFactory {

  @Service(value = PizzaDao.class, locator = DaoLocator.class)
  public interface PizzaRequestContext extends RequestContext {
    Request findById( Long id );
    Request save( PizzaProxy pizza );
  }

  PizzaRequestContext context();
}

With this infrastructure, not only the JS-based client running in the browser but, in fact, any Java client can communicate with your back-end. Although this might not be the full fledged interface for integration with other systems, it is perfectly suitable for running any kind of headless tests against your back-end. This can be functional tests as well as load and performance tests.

All we need to do is to replace the default XHR-based transport layer with a pure JRE compatible implementation. In this example, we use the Apache HttpClient lib. Similar to the tutorial on unit testing a helper class provides a factory method to create RequestFactory instances:

read more »

June 18, 2011

Tutorial GWT Request Factory – Part II

by Stefan

In the first part of the tutorial we set up EntityProxy classes for our back-end entities pizza and ingredient. A PizzaRequestContext was introduced that represents the client-side facade for the PizzaDao in the back-end.

Now, a natural next step is to write some kind of controller logic that uses the PizzaRequestContext to communicate with the back-end. Let’s call this controller PizzaManager:

package cleancodematters.client;

import com.google.web.bindery.requestfactory.shared.Receiver;

public class PizzaManager {

  private final PizzaRequestFactory factory;

  public PizzaManager( PizzaRequestFactory factory ) {
    this.factory = factory;
  }

  public void findById( Long id, Receiver<PizzaProxy> receiver ) {
    factory.context().findById( id ).with( "ingredients" ).fire( receiver );
  }
}

The manager gets a RequestFactory instance passed into the constructor. This is a good idea as creating the RequestFactory requires a GWT#create() call which doesn’t work in plain JUnit tests. See my previous post on how to use GIN get the instance injected automatically.

How can we test the implementation of findById() with plain JUnit tests? One approach is to use a mocked PizzaRequestFactory instance. In our test we then have to ensure that the method chain factory.context().findById( id ).with( "ingredients" ).fire( receiver ) is called correctly. This test code is hard to write and also tied very closely with implementation details. In general, fluent interfaces are nice to read (but often violate the Law of Demeter, btw) but testing this code with mocks can be really cumbersome.

A better approach in my view is to use GWT’s RequestFactory infrastructure and replace the transport layer with some “in memory” processing that is independent of the browser infrastructure. Fortunately, GWT already provides a class for this: InProcessRequestTransport. This approach has another advantage: We also test the error-prone reference of nested entities (with( "ingredients" ) in the example).

read more »

June 4, 2011

Tutorial GWT Request Factory – Part I

by Stefan

Update 30.12.2012: All examples are reviewed and updated to GWT 2.5. Enjoy!
Update 24.09.2011:
I finally managed to push the complete tutorial project to github. It is based on GWT 2.4. 2.5. Looking forward to your feedback.

The first part of this tutorial describes how to set up a Request Factory (RF) based client-server communication in GWT. In contrast to the example at GWT home, a classic DAO pattern is used at the server-side with a clear separation between entity (passive, stateful) and dao/service (active, stateless). As this is not the default way, some additional helper classes (“locators”) need to be implemented. However, I think the benefit of a cleaner architecture is worth the price of some additional lines of code.

The second part will deal with testing RF-based classes in the GWT client.

Prerequisites

You should have the GWT SDK installed and a GWT compatible project in the IDE of your choice available. To make the example run you need some additional libraries on the classpath:

  • org.json.*
  • a JSR 303 Bean Validation implementation, e.g. hibernate-validator

When using Maven, simply add these dependencies:

<dependency>
    <groupId>org.json</groupId>
    <artifactId>json</artifactId>
    <version>20090211</version>
</dependency>

<!-- Validation API -->
<dependency>
    <groupId>javax.validation</groupId>
    <artifactId>validation-api</artifactId>
    <version>1.0.0.GA</version>
</dependency>

<!-- Validation Implementation -->
<dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-validator</artifactId>
 <version>4.3.0.Final</version>
</dependency>

<!-- Need some logging provider for SLF4J -->
<dependency>
 <groupId>ch.qos.logback</groupId>
 <artifactId>logback-classic</artifactId>
 <version>0.9.30</version>
</dependency>

Without Maven you can use gwt-servlet-deps.jar from the GWT SDK (containing the JSON packages) and download the hibernate-validator jar with its dependencies.

read more »

May 29, 2011

Improved ExceptionHandling with GWT RequestFactory

by Stefan

Server Side Exceptions

The default setting for handling exceptions in the server is not optimal. An exception on the server-side is caught and handled by the class DefaultExceptionHandler. Only the exception message is transferred to the client but nothing is logged. As this happens inside an http 200 response, the web app container doesn’t notice that something went wrong. The default behavior can be changed by replacing the DefaultExceptionHandler during the initialization of the RequestFactory servlet.

Therefore, a custom servlet that extends from the default RequestFactoryServlet needs to be defined to pass a custom exception handler in the constructor.

package cleancodematters.server;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.google.web.bindery.requestfactory.server.ExceptionHandler;
import com.google.web.bindery.requestfactory.server.RequestFactoryServlet;
import com.google.web.bindery.requestfactory.shared.ServerFailure;

public class CustomRequestFactoryServlet extends RequestFactoryServlet {

  static class LoquaciousExceptionHandler implements ExceptionHandler {
    private static final Logger LOG = LoggerFactory.getLogger( LoquaciousExceptionHandler.class );

    @Override
    public ServerFailure createServerFailure( Throwable throwable ) {
      LOG.error( "Server error", throwable );
      return new ServerFailure( throwable.getMessage(), throwable.getClass().getName(), null, true );
    }
  }

  public CustomRequestFactoryServlet() {
    super( new LoquaciousExceptionHandler() );
  }
}

read more »

May 19, 2011

GWT RequestFactory with GIN

by Stefan

Creating GWT RequestFactory instances requires a GWT.create() call. These calls should be outside of your classes under test, as GWT.create() internally invokes native JavaScript code. This causes a ExceptionInInitializerError when run as a plain JUnit test.

A very elegant solution is to use Dependency Injection with GIN and let the framework create and assemble both the RequestFactory and corresponding RequestContext instances. In general, using DI is a good idea for all layers of business application, and GIN brings the well-known concepts of Guice into the GWT world.

read more »

May 9, 2011

Having fun with GWT EntityProxies in JUnit tests

by Stefan

GWT comes with a nice feature called RequestFactory that provides a high level abstraction of client-server communication. This includes a mechanism for entity conversion which allows you to have, for instance, JPA-mapped entities in the backend and independent DataTransferObjects (called Entity Proxy)  in the presentation layer. The definition of the Entity Proxies looks like this:

package cleancodematters;

import com.google.gwt.requestfactory.shared.EntityProxy;
import com.google.gwt.requestfactory.shared.ProxyFor;

@ProxyFor(Pizza.class)
public interface PizzaProxy extends EntityProxy {
  void setName( String name );
  String getName();

  void setPrice( Double price );
  Double getPrice();

  boolean isOrdered();
  void setOrdered( boolean ordered );
}

Entity + Interface + Tests = Trouble

As you can see, the entities are in fact interfaces (and created and populated by the framework for you). This has some advantages. For example, GWT can internally track changes and only send deltas over the wire. However, things get complicated when it comes to testing. If you want to create an entity and populate it with two parameters you find yourself writing code like this for every test case:

	PizzaProxy pizza = mock( PizzaProxy.class );
	when( pizza.getName() ).thenReturn( "Funghi" );
	when( pizza.getPrice() ).thenReturn( Double.valueOf(6.99) );

read more »

Tags: , ,