Using Reflection in Unit Tests II

A couple of days ago, I blogged about the pros and cons of using Reflection in unit tests. Thanks to Samuel, who gave me a pointer to "PowerMock", I don't have to deal with the Reflection API anymore.

PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

To be more precise, PowerMock takes away the annoyance of dealing with the Reflection API. In case of the example presented in my previous post, instead of this code:

@Test
public void test_Calculate_Quote() throws Exception {
    Contract classUnderTest = new Contract(1L);
    Method calcMethod = getMethodOfClass(Contract.class, "calculateQuote");
    BigDecimal quote = (BigDecimal) calcMethod.invoke(classUnderTest, new DateMidnight(1982, 4, 27));
    assertEquals(new BigDecimal("7.79"), quote.setScale(2, RoundingMode.FLOOR));
}

private Method getMethodOfClass(Class argClass, String argMethodName) {
    Method[] methods = argClass.getDeclaredMethods();
    for (Method method : methods) {
        if (method.getName().equals(argMethodName)) {
            method.setAccessible(true);
            return method;
        }
    }
    throw new NoSuchMethodError("couldn't find " + argMethodName + " on class " + argClass);
}

you simply write this:

@Test
public void test_Calculate_Quote() throws Exception {
    Contract classUnderTest = new Contract(1L);
    BigDecimal quote = (BigDecimal) Whitebox.invokeMethod(classUnderTest, "calculateQuote", new DateMidnight(1982, 4, 27));
    assertEquals(new BigDecimal("7.79"), quote.setScale(2, RoundingMode.FLOOR));
}

I like the approach of hiding the complexity of the Reflection API behind an abstraction and in case of Whitebox it's even named perfectly. But accessing private methods is not the only thing PowerMock lets you do. In addition to much more you can set private fields, invoke hidden constructors and mock static methods. A feature that I really like is mocking final classes or methods, it can be quite helpful, when you are dealing with JDK classes like java.io.File.

I think PowerMock is a great extention to EasyMock and it should go into every developer's tool box. It's definitely going straight into mine.

SpringOne 2009

Next week, starting on the 27th of April there's gonna be SpringOne 2009. That's 3 days straight and full blown intensive Spring!

Unlike the last 2 years, the conference is not going to be held in Antwerp, Belgium - instead it'll take place in Amsterdam, Netherlands. I think it's a nice change. I've never been to Amsterdam before and I even added a couple of days to my trip to explore the city with my wife.

Looking at the first day, there's a bunch of really interesting sessions like "Performance Tuning for Apache Tomcat", "New Features in Spring 3.0" or "Extreme Productivity in Application Development".

I'm really excited to feel some Spring spirit again...

Using Reflection in Unit Tests

A couple of days ago I watched a presentation on Neal Ford's book "The Productive Programmer". He talked about 10 ways to improve your code. One thing, which I found quite innovative, was leveraging Java Reflection to test non-accessible code.

With non-accessible code, I mean private, package-private or protected methods and constructors of your domain or service classes. If you are a test addict like me, you've probably made a method public or protected every now and then, even though it shouldn't be, simply so that you could access it from your test code. Using Reflection instead, is a simple and easy solution, I have never given a thought before.

I came up with a little sample, which you can download or check out on github. Take a look at the following class:

public class Contract {
    private static final Double RATE = 0.3;
    private final Long contractId;
    private BigDecimal quote;
    private Customer owner;

    public Contract(Long argContractId) {
        contractId = argContractId;
        quote = BigDecimal.ZERO;
    }

    /** package */void setOwner(Customer argOwner) {
        owner = argOwner;
        quote = calculateQuote(argOwner.getBirthday());
    }

    private BigDecimal calculateQuote(DateMidnight argBirtday) {
        Years ageInYears = Years.yearsBetween(argBirtday, new DateMidnight());
        return new BigDecimal(RATE).multiply(new BigDecimal(ageInYears.getYears()));
    }
    // other stuff omitted
}

In order to test the calculateQuote method in isolation, I would have probably introduced a QuoteCalculator class. It would be in charge of the business logic and used by the Contract class. If you need the logic at multiple places in your code, that's a great solution. If you only need it in Contract, it's quite tedious and I would have probably made calculateQuote accessible from the test class. However, I used Reflection instead to solve the problem and it works quite nicely:

@Test
public void test_Calculate_Quote() throws Exception {
    Contract classUnderTest = new Contract(1L);
    Method calcMethod = getMethodOfClass(Contract.class, "calculateQuote");
    BigDecimal quote = (BigDecimal) calcMethod.invoke(classUnderTest, new DateMidnight(1982, 4, 27));
    assertEquals(new BigDecimal("7.79"), quote.setScale(2, RoundingMode.FLOOR));
}

private Method getMethodOfClass(Class argClass, String argMethodName) {
    Method[] methods = argClass.getDeclaredMethods();
    for (Method method : methods) {
        if (method.getName().equals(argMethodName)) {
            method.setAccessible(true);
            return method;
        }
    }
    throw new NoSuchMethodError("couldn't find " + argMethodName + " on class " + argClass);
}

As you can see the method.setAccessible(true); is doing the trick to enable access from the test to the domain object. Instead of the actual instance of Contract, we use the Method instance to invoke the private call. Everything else is plain test code, as you know it.

Of course, you could argue to make the calculateQuote method package-private or protected and put the test class into the same package. In fact Bill Venners wrote about that in one of is articles, suggesting that testing private methods is bad practice anyways. I tend to agree and I guess the example above is an exception. However, using Reflection is not necessarily limited to testing private methods. You might need access to an object to manipulate it's internal state, in order to test it thoroughly and the best tool for that job is probably Reflection.

I think it's a neat idea to use Reflection in unit tests. Used with caution, it can be really helpful and is definitely better than breaking encapsulation for testing.

More Playing with GAE

In my previous blog about the Google App Engine (GAE), I wrote about the problems I had encountered using JPA and Maven. In this post I want to share how using Groovy on the GAE worked out and what my impressions are on the scalability of the platform.

Inspired by SpringSource's blog on Groovy with the GAE and after almost a year, I decided to do some Groovy coding. I wrote a small Groovlet, which uses the JPA to fetch entities from persistent storage. Again, I'm quite astonished of how smooth coding can be:

import javax.persistence.*
import java.util.List
import de.linsin.sample.gae.domain.User 
import de.linsin.sample.gae.EMF
 
EntityManager em = EMF.getInstance().createEntityManager()
Query query = em.createQuery("SELECT u FROM " + User.class.getName() + " u")
List<User> users = query.getResultList()

for (User user : users) {
  out.println(user.getName() + " " + user.getLastname() + "<br/>")
}

em.close();

To be fair, I have no Exception handling in this code and there is no finally making sure the EntitManager is closed at the end. Yet, it feels like Java without the clutter.

To get this working on the GAE, all you need to do is drop the groovy-all.jar into the WEB-INF/lib folder of your WAR file and add the GroovyServlet to your web.xml. You add your Groovlet to a groovy folder under WEB-INF and access it like a good old Servlet in your browser e.g. http://dlinsin-area51.appspot.com/HelloWorld.groovy.

Unfortunately there is one major drawback, which makes developing Groovy for GAE a real pain - local deployment of Groovlets is not working right now. It seems like Google has been notified about the issue, but even after a few days the bug is still in status "new", so I don't think there'll be a fix anytime soon. Since daily deployment is limited by a quota, I think this bug is almost a show-stopper and I wouldn't want to develop in Groovy for the GAE right now.

Let's turn our attention to performance and scalability. First off I have a disclaimer: I didn't run any thorough or scientific tests! Although I have some numbers to back up my opinion, you might want to run further tests before you draw a final conclusion.

To get us all on the same page, let's start with a little "theory". When I talk about performance it means something like this:

... performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used.

...performance may involve one or more of the following:

Short response time

High throughput

The same goes for scalability, although in general it's more subtle to properly define it:

...scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged.

With that out of the way let's head over to the test setup. It consists of a simple Apache JMeter test script, which puts my poor sample application under load. The script loads the start page http://dlinsin-area51.appspot.com, then inserts the name "JMeter" into the input field and submits the form. The submission results in a redirect to the start page again. I mainly wanted to test "writes" to the persistent storage, because in my experience that's the most hardest part to scale.

I ran the test script with 10 threads (blue shaded) and with 100 threads hitting my sample app. Each thread runs the test procedure 10 times. The results were quite interesting. If you take a closer look at the average response time of both samplers you can see only a small difference between 10 users and 100 users (or threads) hitting the application at the same time. The response time for inserting a row into the persistent storage went up insignificantly, which I think is quite astonishing, considering the increase of load.

However, you should take these results with a grain of salt. They merely exist to give me a hint of what the GAE is capable of. I would be interested in real benchmarks, because I think it's crucial to see how scalable the GAE is under field conditions.

Update: The test results are simply wrong! Thx for pointing it out Bernd, I'm working on it!

Update 2: Here comes the bugfix!

You might ask what happened? Frankly, I mixed up the pictures and didn't double check, before pushing out the post. Sorry about that! I ran the tests with the same specs as mentioned above again and as you can see from the results, this time it looks reasonable.

Based on the new numbers, I have to put my conclusion a little bit into perspective. It still think the GAE scales reasonably well, but the numbers are not that astonishing anymore.

Playing with Google App Engine

I'm jumping on the hype wagon and checking out the Google App Engine (GAE) for Java. After writing a simple sample application using Servlets, Groovlets and the JPA, I want to share with you the bumpy ride I had.

If you are interested in checking out the sample application you can either download it or check it out on github.

Fankly, I only had a bumpy ride, because I didn't follow Google's suggestion to use the Eclipse IDE plug-in together with a set of ANT tasks, they provide. Instead I wanted to use IntelliJ and Maven. Another suggestions of Google I didn't follow, is to use Java Data Object (JDO) as a persistence API. Yes, that's right, Google suggests JDO as a preferred way to store data. If you are working on a somewhat up to date Java enterprise application, you are probably using the Java Persistence API (JPA) instead. The difference between the two standards, according to wikipedia, are:

... JPA, however, is an Object-relational mapping (ORM) standard, while JDO is an Object-relational mapping standard and a transparent object persistence standard. JDO, from an API point of view, is agnostic to the technology of the underlying datastore, whereas JPA is being oriented totally around RDBMS datastores.

Google's underlying persistence layer is called Bigtable. It's designed to scale across distributed systems, by being non-relation. That means you can dump your data into Bigtable, without brooding over your schema first. On the question why Google favors JDO over JPA, I think it's because you are not dealing with an RDBMS, but Bigtable.

The first thing I did was to write a simple hello world JSP and Servlet and packaged it as a WAR file. Thanks to IntelliJ's built-in enterprise support, I was up and running in no more than 10 minutes. The only difference to a regular enterprise application is the file appengine-web.xml. It contains your application identifier and version. The versioning schema is quite interesting. You can configure which version a user sees and simultaneously deploy a new version for testing.

Google provides a couple of command-line tools, which help you to start a local version of the app engine and upload your application to the cloud. Once you are online, you can access your server logs through a dashboard. Unfortunately I wasn't able to see the logs instantly, after encountering errors. I had to wait for a couple of seconds, which is pretty annoying and makes local testing much more important.

The first hurdle I had to overcome was integrating JPA. Google uses an implementation called DataNucleus, which relies on post-compile bytecode manipulation of your entities. I had the hardest time integrating the bytecode manipulation with my Maven build. Fortunately, the App Engine Google Group was very helpful and the problem was solved quickly. After a couple of hours, I was able to run my first JPA enabled application, without thinking about deployment or database issues. No problems with getting a server to run or twiddling with database settings - the stuff just runs.

As a developer, your probably don't want be bothered with infrastructure, which sometimes looks like black magic. I really like the completely transparent way of developing for the GAE, but I'm skeptical if I'd want to rely my business on this kind of hosting. With Amazon's EC2 you still have the configuration of the system under control and that's probably important, if you want to run a business on it. In terms of pricing, I can't really say much. To me it looks almost the same, except that with GAE you have a quota on everything. There's even a daily quota on datastore API calls, which can't be increased even by paying for it. That's a bit of a bummer! However, I think they chose the quotas reasonably and maybe the are being increased after the public release of the GAE for Java.

In my next blog post, I will cover some more details on how to run Groovlets. I also did some simple load testing with Apache JMeter to get a feeling on how GAE scales.

The State Pattern

A couple of weeks ago I had to come up with a design for a state machine at work. Even though a colleague mentioned the State Pattern, I thought it was oversized and being the pragmatic programmer I am, I decided to take the easy turn.

I've never really used the State Pattern before and I have to admit, even after glancing at the UML diagram, I couldn't quite figure out how this is gonna help me solve my problem. In case you are like me and need a little recap on the State Pattern, let's look at the wikipedia summary:

The state pattern is a behavioral software design pattern, also known as the objects for states pattern. This pattern is used in computer programming to represent the state of an object. This is a clean way for an object to partially change its type at runtime.

from wikipedia

Starting from this description, it seemed like there is a hammer, which looks for a nail. Having a concrete state class for each state in my design? I'm going to end up with a truckload full of classes and they all need to be carefully designed and tested.

With this mindset, I went down the switch/case-if/else road and designed the state machine in the most straight forward, but most unmaintainable way possible. Here's an imperative style code sample, which points out how not to implement a state machine:

public void insertCoins() {
  if (state == NO_COINS && numberOfCoins >= MIN_COINS) {
    state = COINS_OK;
  } else if (state == NO_COINS && numberOfCoins < MIN_COINS) {
    state = NO_COINS;
    System.out.println("more coins!");
  } else if (state == SOLD_OUT) {
    state = RETURN_COINS;
  }
}
// more transitions like dispenseFood(), printReceipt() and soldOut()

If you are like me and have never used the State Pattern, you probably think "What is wrong with this code?". The answer is nothing! It's just very imperative and highly unmaintainable. Imagine if you have to add a new state, you will need to adopt every if/else blocks in each transition method. In addition to that, you need to update each test case you wrote.

After reading on the State Pattern in Head First Design Patterns, which explains it very visually, I would change my code above into something like this:

public class NoCoins implements State {
  public void insertCoins() {
    if (numberOfCoins >= MIN_COINS) {
      context.setCoinsOk();
    } else {
      System.out.println("more coins!");
    }
  }
  // more methods defined in State, like dispenseFood()...
}

public class SoldOut implements State {
  public void insertCoins() {
    context.returnCoins();
  }
  // more methods defined in State, like dispenseFood()...
}

Each state gets a concrete class and common functionality can be aggregated in an abstract super class (I used an interface here instead). The member context is the representation of the state machine, which is used by the client to transition between states.

The main advantages of the State Pattern, according to Head First Design Patterns, are:

unlike a procedural state machine, it represents state as a full-blown class

the context object gets its behavior by delegating to the current state object

it allows a context to change its behavior as the state of the context changes

My state machine implementation was pretty simple, so I couldn't see any downside using the imperative approach. However, trying to test the beast ended up to be much more complicated than the implementation itself. A colleague pointed out the design smell (thanks Alexander).

With the State Pattern, each state is represented by a class, it can be tested in isolation. I think that is one of the most compelling advantages. It outweighs the argument, that you have much more classes than with an imperative approach.

I really enjoyed reading up on the State Pattern in Head First Design Patterns. Each comes with a visually rich example, giving you everything, needed to use it in your code. It even compares a procedural/imparative implementation of a state machine with the much more improved version using the State Pattern. I find that one of the most effective ways to learn.