Getting Started with EasyMock2

Unit tests are no longer hype, but daily business. Developers love writing tests, and even do test-driven development. But testing units of code often is a problem: most parts of a software system do not work in isolation, but collaborate with other parts to get their jobs done. In unit testing, we do not want to test these collaborating objects, but only the unit under test. Mock objects provide a solution to this dilemma: they can be set up to behave as expected, so they are a perfect replacement for collaborators of the unit under test.

Writing mock objects on your own can be tedious, but there are a lot of mock frameworks out there to help you with this task. EasyMock is a library for creating mocks for interfaces on the fly using the dynamic proxy API. It's been around for a couple of years now, and besides being very stable and robust, another advantage is that it is well known. So here comes EasyMock2, ready to rock--er, mock--the world. My first idea was to introduce only the new features of version 2, but I recognized that there are still a lot of people out there not using EasyMock at all. So I'm going to show what you can do with EasyMock using the new version 2.2 API.

For those out there who already know EasyMock: What's so special about version 2? Well, for me it eliminates the weaknesses of EasyMock1; the price is that it depends on JDK1.5. Have a look at the new features:

• No more need for a dedicated control object.

• Heavy usage of generics eliminates casts.

• New matcher API allows fuzzy parameter matching.

• Check call order of more than one mock.

• Dynamically respond to mock method calls.

Curious? Let's get started.

Personally, I prefer learning by example. That's why we will develop some code here in a test-first manner using EasyMock2. You're not familiar with test-first development? Don't worry, it's quite natural; but reading one of these papers first will help.

Last Exit to Springfield

What's the problem we have to solve? Here we go: the application we're building is the SimpsonViewer, which one can use to watch episodes of The Simpsons [2]. The application is based on an IoC container like Hivemind [3] and is divided into client and server parts. We have a web service that delivers Simpsons episodes, the ISimpsonService. The client uses this service to fetch episodes and renders them to the user. A flaw in our application is that every time the user selects an episode she likes to watch, the client fetches the episode from the server, even if this episode has already been retrieved. So we'd like to introduce a client-side proxy that transparently caches the episodes. Let's start with the ISimpsonService:

public interface ISimpsonService {
    IEpisode getEpisode(int number);
}

Quite easy. The IEpisode interface looks like this:

public interface IEpisode {
    int getNumber();
   String getTitle();
   InputStream getDataAsStream();
}

Not that complicated. Now we have to implement our ClientSimpsonService, which is the client-side proxy for the web service:

public class ClientSimpsonService implements ISimpsonService {
    private ISimpsonService remoteSimpsonService;
    public ClientSimpsonService(ISimpsonService remoteSimpsonService) {
        this.remoteSimpsonService = remoteSimpsonService;
    }
    public IEpisode getEpisode(int episodeNumber) {
        return null;
    }
}

The ClientSimpsonService gets the remote service as a constructor parameter injected by the IoC container. We could also have done this with a setter, but I prefer passing mandatory parameters in the constructor, so we can "fail fast" if the service is not set up correctly.

OK, this is an implementation, but it's not very useful right now. That's fine, as we want to develop in a test-first style, so let's specify the expected behavior of the code in a unit test. We want to fail fast if the service is not set up correctly; in this case, this means we have to check that we actually get the remoteSimpsonService passed in:

public class ClientSimpsonServiceTest extends TestCase {
    public void testClientSimpsonService() {
        try {
            new ClientSimpsonService(null);
            fail("Expected IllegalArgumentException");
        } catch (IllegalArgumentException e) {
            // expected
        }
    }

So passing a null should raise an IllegalArgumentException. Developing test-first means "write the easiest implementation that does the job."

public class ClientSimpsonService implements ISimpsonService {
...
    public ClientSimpsonService(ISimpsonService remoteSimpsonService) {
        this.remoteSimpsonService = remoteSimpsonService;
        throw new IllegalArgumentException();
    }
...
}

You can't be serious! Run the test, please. Green, isn't it? That means our test case doesn't prove much yet. The constructor should not always throw an IllegalArgumentException, but instead only does so if the parameter is null. So we have to write a test that does not fail if we pass an ISimpsonEpisode instance. Too bad we don't have any other implementation we could use. But here comes EasyMock to the rescue:

import static org.easymock.EasyMock.createMock;
import junit.framework.TestCase;
public class ClientSimpsonServiceTest extends TestCase {
    private ISimpsonService remoteSimpsonServiceMock;
    protected void setUp() throws Exception {
        super.setUp();
        remoteSimpsonServiceMock =
            createMock(ISimpsonService.class);
    }
    public void testClientSimpsonService() {
        try {
            new ClientSimpsonService(null);
            fail("Expected IllegalArgumentException");
        } catch (IllegalArgumentException e) {
            // expected
        }
        new ClientSimpsonService(remoteSimpsonServiceMock);
    }
}

What's happening here? In a few words: we used EasyMock to create an instance that implements the ISimpsonEpisode interface on the fly and passes it to the constructor and everything should be fine. This means our test should now run red--yep, as expected. And now the implementation that makes our bar green again:

public class ClientSimpsonService implements ISimpsonService {
...
    public ClientSimpsonService(ISimpsonService remoteSimpsonService) {
        if (remoteSimpsonService == null) {
            throw new IllegalArgumentException(
                "'remoteSimpsonService' must not be null");
        }
        this.remoteSimpsonService = remoteSimpsonService;
    }
...
}

I can hear you yelling: "Why is he taking such damn small steps? I would have written the correct code in the first place." No doubt about it. But would your test look the same? The point is: taking small steps, and using the simplest implementation you can think of, forces you to write the right tests. Always check that adding a test turns the test bar red. If not, there is something wrong with your test.

Now let's move on to the getEpisode() method. Let's ignore the caching for now and start with testing that the client delegates the call to the remote service. Er, how do we do that? Well, EasyMock allows us the specify expectations:

import static org.easymock.EasyMock.createMock;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;
import static org.easymock.EasyMock.verify;
import junit.framework.TestCase;
public class ClientSimpsonServiceTest extends TestCase {
    private IEpisode episode17Mock;
    private ISimpsonService remoteSimpsonServiceMock;
    protected void setUp() throws Exception {
        super.setUp();
        episode17Mock = createMock(IEpisode.class);
        remoteSimpsonServiceMock =
            createMock(ISimpsonService.class);
    }
...
    public void testGetEpisode() throws Exception {
        expect(remoteSimpsonServiceMock.getEpisode(17))
            .andReturn(episode17Mock);
        replay(remoteSimpsonServiceMock);
        ISimpsonService clientSimpsonService = 
            new ClientSimpsonService(remoteSimpsonServiceMock);
        IEpisode result = clientSimpsonService.getEpisode(17);
        verify(remoteSimpsonServiceMock);
        assertEquals(episode17Mock, result);
    }

We'll take this step by step:

• We expect that our remote service mock's getEpisode() method is called with the parameter 17.

• The previous expect() call returns an IExpectationsSetters, which we use to instruct EasyMock to return the episode17Mock for that call.

• We switch the mock to replay mode, which means that from now on it is expecting the call.

• We call our client's getEpisode() method with the parameter 17.

• We verify that our expectations have been met, which means that getEpisode(17) has been called on the remoteSimpsonServiceMock.

• We check if the service returned the episode17Mock.

Run the test, and--yep, red. An AssertionError has been thrown. Let's have a look at the StackTrace:

java.lang.AssertionError: 
  Expectation failure on verify:
    getEpisode(17): expected: 1, actual: 0
        at org.easymock.internal.MocksControl.verify(MocksControl.java:70)
        at org.easymock.EasyMock.verify(EasyMock.java:1301)
        at example1.ClientSimpsonServiceTest.testGetEpisode(ClientSimpsonServiceTest.java:41)
        ...

The verify() failed, since the expected call getEpisode(17) has not been made. This makes sense: we did not call the remote service (-mock) yet. And again, we write the easiest implementation that colors the test bar green:

public class ClientSimpsonService implements ISimpsonService {
...
    public IEpisode getEpisode(int episodeNumber) {
        return remoteSimpsonService.getEpisode(episodeNumber);
    }
}

Run the test and--ta da, green again. Hey, easy on the clutch. How is that working? You're right, it's time for some words on EasyMock. Using EasyMock always follows the same steps:

1. Create a mock.

2. Set up your expectations.

3. Set the mock to replay mode.

4. Call your code under test.

5. Verify that your expectations have been met.

How is EasyMock creating a mock? It uses the DynamicProxy API to generate a class that implements the desired interface on the fly. This has a great advantage over writing your own mock. First of all, you don't have to write one ;-). Another advantage is that it is robust to interface changes, which means that if things have been altered (that are not explicitly used in your test case), you don't have to worry about it. If you write your own mock, you have to follow every interface change. (Once upon a time, I was working in a project where management decided to use an API that was still in its beta state. Besides having no robust implementation, even mocking was a pain, since the API interfaces changed almost weekly!) There is nothing much to say about replay() and verify(). But what you can do to set up expectations is worth having a look. Setting up your expectations means you tell EasyMock which calls to expect on a certain mock, and what to return for that call. You can certainly expect more than one call, e.g.:

expect(remoteSimpsonServiceMock.getEpisode(17))
    .andReturn(episode17Mock);
expect(remoteSimpsonServiceMock.getEpisode(43))
    .andReturn(episode43Mock);
replay(remoteSimpsonServiceMock);

If you are expecting the same call more than once, there is a shortcut. Let's say we expect the call exactly twice:

expect(remoteSimpsonServiceMock.getEpisode(17))
    .andReturn(episode17Mock).times(2);
...

Since andReturn() (and all other methods of IExpectationsSetters) returns the IExpectationsSetters instance itself, these calls can be easily chained. There are also some methods that specify a fuzzy number of method calls:

• atLeastOnce()

• anyTimes()

• times(from, to)

If you don't specify a call count, it is implicitly once(). Sometimes you want your mock to return values for method calls, but you don't care how often it is called or even if it is called at all: you want to use it as a stub. EasyMock supports this by using the methods andStubReturn() and asStub().

Another thing to note is that after verify(), the mock is not burned; you can reuse it by calling reset():

import static org.easymock.EasyMock.reset;
...
public class ClientSimpsonServiceTest extends TestCase {
...
    public void testGetEpisode() throws Exception {
        expect(remoteSimpsonServiceMock.getEpisode(17)).
            andReturn(episode17Mock);
        replay(remoteSimpsonServiceMock);
        ISimpsonService clientSimpsonService = 
            new ClientSimpsonService(remoteSimpsonServiceMock);
        IEpisode result = clientSimpsonService.getEpisode(17);
        verify(remoteSimpsonServiceMock);
        assertEquals(episode17Mock, result);
        reset(remoteSimpsonServiceMock);
        expect(remoteSimpsonServiceMock.getEpisode(43)).
        andReturn(episode43Mock);
        replay(remoteSimpsonServiceMock);
        result = clientSimpsonService.getEpisode(43);
        verify(remoteSimpsonServiceMock);
        assertEquals(episode43Mock, result);
    }
...
}

Introducing the Cache

What have we got so far? Our ClientSimpsonService delegates to the remote service. Fine. But the feature we wanted to introduce was client-side caching, so let's start implementing that. Again, we will specify our test first. How do we test caching? Let's think about it: once an episode is fetched, it must not be retrieved from the remote service again. This means that if we ask for the same episode twice, it should be retrieved from the server just once; the second time it should be retrieved from the cache:

public void testGetEpisodeCaches() throws Exception {
    expect(remoteSimpsonServiceMock.getEpisode(17))
        .andReturn(episode17Mock);
    replay(remoteSimpsonServiceMock);
    ISimpsonService clientSimpsonService = 
        new ClientSimpsonService(remoteSimpsonServiceMock);
    assertEquals(episode17Mock, clientSimpsonService.getEpisode(17));
    // not expected since it should be cached
    assertEquals(episode17Mock, clientSimpsonService.getEpisode(17));
    verify(remoteSimpsonServiceMock);
}

Hmm, not that complicated. We set up the remote service mock to expect one call to getEpisode(17), but we call it twice on the client service. Curious about the test result? Run the test--red, as expected. And here is the StackTrace:

java.lang.AssertionError: 
  Unexpected method call getEpisode(17):
    getEpisode(17): expected: 1, actual: 1 (+1)
      at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
      at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:45)
      at $Proxy1.getEpisode(Unknown Source)
      at example2.ClientSimpsonService.getEpisode(ClientSimpsonService.java:20)
      at example2.ClientSimpsonServiceTest.testGetEpisodeCaches(ClientSimpsonServiceTest.java:62)
      ...

Yep, when the unexpected call comes, EasyMock complains that getEpisode(17) has been called one more time (+1) than expected. Note: In EasyMock1, the message would have been getEpisode(17): expected: 1, actual: 2 .

To see if our test checks the right thing, we choose the simplest implementation we can think of:

public class ClientSimpsonService implements ISimpsonService {
    private IEpisode cachedEpisode;
    ...
    public IEpisode getEpisode(int episodeNumber ) {
        if (cachedEpisode == null ) {
            cachedEpisode = remoteSimpsonService.getEpisode(episodeNumber);
        }
        return cachedEpisode;
    }

This is ridiculous. Absolutely right, but our test says green. OK, so our test isn't worth a nickel yet. Let's change that by asking for more than one episode:

public class ClientSimpsonServiceTest extends TestCase {
    private IEpisode episode42Mock;
        ...
    protected void setUp() throws Exception {
        ...
        episode42Mock = createMock(IEpisode.class);
    }
    ...
    public void testGetEpisodeCaches() throws Exception {
        expect(remoteSimpsonServiceMock.getEpisode(17))
            .andReturn(episode17Mock);
        expect(remoteSimpsonServiceMock.getEpisode(42))
            .andReturn(episode42Mock);
        replay(remoteSimpsonServiceMock);
        ISimpsonService clientSimpsonService =
            new ClientSimpsonService(remoteSimpsonServiceMock);
        assertEquals(episode17Mock,
                     clientSimpsonService.getEpisode(17));
        assertEquals(episode42Mock,
                        clientSimpsonService.getEpisode(42));
        // not expected since it should be cached
        assertEquals(episode17Mock,
                     clientSimpsonService.getEpisode(17));
        assertEquals(episode42Mock,
                        clientSimpsonService.getEpisode(42));
        verify(remoteSimpsonServiceMock);
    }
}

Run the test and--red. Fine, the test now specifies the required behavior. And the final code to satisfy our test looks like this:

public class ClientSimpsonService implements ISimpsonService {
    private Map<Integer, IEpisode> episodeCache =
        new HashMap<Integer, IEpisode>();
    ...
        
    public IEpisode getEpisode(int episodeNumber) {
        IEpisode episode = episodeCache.get(episodeNumber);
        if (episode == null) {
            episode = remoteSimpsonService.getEpisode(episodeNumber);
            episodeCache.put(episodeNumber, episode);
        }
        return episode;
    }
}

Run the test again. Yippee, it's green. So we're done with caching.

Testing Exceptions

Currently, if an episode is not found, null is returned. That's OK, but client code always has to check for null before using an episode. We'll take a different approach: If an episode cannot be retrieved, an EpisodeNotFoundException is thrown:

public interface ISimpsonService {
    IEpisode getEpisode(int number) throws EpisodeNotFoundException;
}

After changing the interface, our compiler complains that ClientSimpsonService calls getEpisode() on the remote service and does not handle the EpisodeNotFoundException. Eclipse suggests corrections if you press CTRL-1; we decide to use Surround with try/catch:

public IEpisode getEpisode(int episodeNumber) {
    IEpisode episode = episodeCache.get(episodeNumber);
    if (episode == null) {
        try {
            episode = remoteSimpsonService.getEpisode(episodeNumber);
        } catch (EpisodeNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        episodeCache.put(episodeNumber, episode);
    }
    return episode;
}

Now it compiles, but is that the desired behavior of our ClientSimpsonService? Nope. It should pass the exception thrown by the server, so let's write a test for that:

public void testGetEpisodeThrowsException() throws Exception {
    EpisodeNotFoundException exception = 
        new EpisodeNotFoundException();
    expect(serverSimpsonServiceMock.getEpisode(666)).andThrow(exception);
    replay(serverSimpsonServiceMock);
    ISimpsonService clientSimpsonService = 
        new ClientSimpsonService(serverSimpsonServiceMock);
    try {
        clientSimpsonService.getEpisode(666);
        fail("Expected EpisodeNotFoundException");
    } catch (EpisodeNotFoundException e) {
        // expected
    }
    verify(serverSimpsonServiceMock);
}

In our previous tests, we always used the IExpectationsSetters to set up return values. This time, we use the method andThrow() to set up throwables, meaning that on the call getEpisode(17) the mock is throwing the EpisodeNotFoundException. After that, we call getEpisode(17) on our ClientSimpsonService and fail if the exception is not thrown. Run the test and--yep, it's red. (You should always run the test before fixing the code; checking for red is a test for your test.) To fix our ClientSimpsonService, we simply remove the try/catch and add a throws declaration:

public IEpisode getEpisode(int episodeNumber) throws EpisodeNotFoundException {
    IEpisode episode = episodeCache.get(episodeNumber);
    if (episode == null) {
        try {
            episode = remoteSimpsonService.getEpisode(episodeNumber);
        } catch (EpisodeNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        episodeCache.put(episodeNumber, episode);
    }
    return episode;
}

And out test is green again! EasyMock also supports stub behavior for throwables by the method andStubThrow().

The Mapper API

Suppose we'd like to introduce a method that allows us to retrieve a collection of episodes:

public interface ISimpsonService {
    IEpisode getEpisode(int number) throws EpisodeNotFoundException;
        
    List<IEpisode> getEpisodes(int[] numbers);
}

Writing a test for this method seems to be straightforward. It's similar to our test for the getEpisode() method, only the parameter is an array and the return value is a List:

public void testGetEpisodes() {
    List<IEpisode> expectedResult = 
        Arrays.asList(new IEpisode[] {episode17Mock, episode42Mock});
    expect(remoteSimpsonServiceMock.getEpisodes(new int[] {17, 42})).
        andReturn(expectedResult);
    replay(remoteSimpsonServiceMock);
    ISimpsonService clientSimpsonService = 
        new ClientSimpsonService(remoteSimpsonServiceMock);
    assertEquals(expectedResult,
                clientSimpsonService.getEpisodes(new int[] {17, 42}));
    verify(remoteSimpsonServiceMock);
}

Hmm, quite easy. It's the same with our ClientSimpsonService implementation:

public class ClientSimpsonService implements ISimpsonService {
    ...
    public List<IEpisode> getEpisodes(int[] episodeNumbers) {
        return remoteSimpsonService.getEpisodes(episodeNumbers);
    }
}

Run the test, and--er, red?!? What? Why is that? Let's see the error message:

java.lang.AssertionError: 
  Unexpected method call getEpisodes([I@1dff3a2):
    getEpisodes([I@a9ae05): expected: 1, actual: 0
      at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
      at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:45)
      at $Proxy1.getEpisodes(Unknown Source)
      at example4.ClientSimpsonService.getEpisodes(ClientSimpsonService.java:30)
      at example4.ClientSimpsonServiceTest.testGetEpisodes(ClientSimpsonServiceTest.java:92)
      ...

We expected an array new int[] {17, 42} and we passed an int[] {17, 42}. So what's the problem? Ever asked yourself how EasyMock decides if passed parameters match the expectations? It uses the equals() method, which is quite fine in most circumstances. Most, but not all. For example, you can't compare arrays using the equals method (that's why there is a static method Arrays.equals(Object [] a, Object[] b) and signatures for all kind of primitive types as well). For those circumstances, EasyMock2 introduced the new matcher API. In our case here, we need an array matcher:

import static org.easymock.EasyMock.aryEq;
...
public class ClientSimpsonServiceTest extends TestCase {
...
    public void testGetEpisodes() {
        List<IEpisode> expectedResult = 
            Arrays.asList(new IEpisode[] {episode17Mock, episode42Mock});
        expect(remoteSimpsonServiceMock.getEpisodes(aryEq(new int[] {17, 42}))).
            andReturn(expectedResult);
        replay(remoteSimpsonServiceMock);
        ISimpsonService clientSimpsonService = 
            new ClientSimpsonService(remoteSimpsonServiceMock);
        assertEquals(expectedResult,
                     clientSimpsonService.getEpisodes(new int[] {17, 42}));
        verify(remoteSimpsonServiceMock);
    }
}

Run the test again, and ta da: green!

And now the EasyMock1-wise-guys choir: What's the big deal? EasyMock1 already provided an array matcher! Right, but besides the fact that its usage wasn't quite that elegant, there wasn't this choice of matchers:

• eq(X value), eq(X value, X delta)
• anyBoolean(), anyByte(), anyChar(), anyDouble(), anyFloat(), anyInt(), anyLong(), anyObject(), anyShort()
• aryEq(X value)
• isNull(), notNull()
• same(X value)
• isA(Class clazz)
• lt(X value), leq(X value), geq(X value), gt(X value)
• startsWith(String prefix), contains(String substring), endsWith(String suffix), matches(String regex), find(String regex)
• and(X first, X second), or(X first, X second), not(X value)

What's Left?

There are still some features worth getting to know. Since I had no use for them in our trivial example, I will just explain them shortly here:

Nice Mocks

Mocks created by EasyMock usually throw an AssertionError for all unexpected method calls. Sometimes you need a mock that nicely returns default values instead of complaining all the time. Mocks created by EasyMock.createNiceMock() return empty values (0, null, or false) for unexpected method calls.

Strict Mocks

By default, the order of method calls is not checked by EasyMock. If you need this, you have to create a Strict Mock with EasyMock.createStrictMock(). You can even switch from strict to normal by EasyMock.checkOrder(Object mock, boolean enableOrderCheck).

Checking Call Order Between Mocks

If there is more than one mock involved with your test, you might want to check the call order between mocks. This means that if you have mock1 and mock2, you can check that mock1.a() is called before mock2.b(). Before I show you how to achieve that, let me introduce the IMockControl: when you call EasyMock.createMock(), an IMockControl is also created and maintained for you under the hood. When you now call, for example, replay(myMock), the associated IMockControl is retrieved and replay() is called on it. You can also create an IMockControl explicitly using EasyMock.createControl() or--since we want to check call order--createStrictControl(). Now you can use this instance to create two or even more mocks, which are all under control of this single IMockControl.

Note: In EasyMock1, you always had to create and maintain an explicit MockControl object.

Dynamically Respond to Mock Method Calls

There might be the rare case that you need to execute some code when a mock object is called, maybe to trigger some side effects. Or maybe you don't know the parameters passed to the mock up front, so you need to create the appropriate return value on the fly? For those situations, EasyMock 2.2 introduced the IAnswer interface and the static methods andAnswer() and andStubAnswer().

Note: The method callback(Runnable), which has been introduced with 2.0, has now been replaced by the more flexible andAnswer() in Version 2.2.

What about Mocking Classes with EasyMock?

So far we've used EasyMock to create mocks for interfaces, but how about mocking classes? Is that possible? No. Er, yes. Er, well, EasyMock itself is capable of mocking interfaces only. But there is another project called EasyMock Class Extension that fills this gap. Just use the org.easymock.classextension.EasyMock.* methods instead. You may even mock abstract classes. Unfortunately (but not surprisingly), you can't mock final classes.

Mocking Methods

Another valuable feature is EasyMock Class Extension's ability to mock only certain methods. This means that you can mock one (or more) methods but leave the rest of the objects' functionality untouched. The point is that you do not need to rebuild all of the objects' behavior in your setup, but only those calls you have to avoid in your testing environment.

That's It, Dude

Wake up, we're done. Didn't talk you into a coma with all those nifty little details? That's good news. We have gone through some common usage examples of EasyMock, and even scratched the surface of some sophisticated features. What's next? Check out EasyMock and give it a try in your current project. Or replay the examples we have gone through; you will find all the example code of this article in the Resources section. If you're still not sick of all that theory, you could read the EasyMock documentation. That's all I have to say; hope to see you again on my next article. And remember:

You're damned if you do, and you're damned if you don't.
--Bart Simpson

Resources

• Source code of this article [4]
• EasyMock [5]
• EasyMock 2.2 documentation [6]
• Test-driven development [7] from Wikipedia
• "Test-Driven Development: A Conversation with Martin Fowler, Part V [8]"

Ralf Stuckert [1] is an IT consultant for compeople AG [9], a European IT-Service company located in Frankfurt, Germany.

Related Topics >> Testing [10]   |