Using PowerMock to Test Singletons

I’ve been trying to test a small suite of classes based around exception handling. One of the classes is a class factory implemented as a singleton, which has proved impossible to test with the usual techniques, i.e. sub-class and override and Mockito.

A class factory is a class used to create and initialise other classes. A singleton class is designed only to be instantiated once and then every use afterwards uses the same instance over and over again, rather than creating multiple copies of the same class.

Sub-class and override is a technique used to isolate various methods of a class during testing. Take a simple class like this:

public class DemoSuperClass {

    protected List createNameList() {
        List returnList = new ArrayList();

        returnList.add("Steve Stranger");
        returnList.add("James Jones");
        returnList.add("Harry Harnot");
        returnList.add("Bill Blogger");

        return returnList;
    } 

    public void printNameList() {
        List nameList = createNameList();
        for(String name: nameList)
            System.out.printLn(name.split(" ")[0]); //prints the first name
    }

}

Say you want to test printNameList but with an empty list of names, or different names. The best way to do this is in the test harness declare a sub-class of DemoSuperClass and override createNameList:

private class DemoSubClass { //class in the test harness

    @Override
    protected List createNameList() {
        List returnList = new ArrayList();
        return returnList;
    } 
}

Now the sub-class can be tested.

Even if the method being overridden is called by the constructor, it will still work:

public class DemoConstructorClass {

    protected DemoConstructorClass() {
        procedure1();
    }

    protected void procedure1() {
        System.out.println("procedure1");
    }
}

    //in the test harness
    private class TestDemoConstructor extends DemoConstructorClass {

        @Override
        protected void procedure1() {
            System.out.println("Overriden procedure1");
        }
        
    }

Where this won’t work is in testing singletons. The singleton I’m trying to test looks something like this:

public class SingletonClass {
    private static SingletonClass instance = new SingletonClass();

    public static SingletonClass getInstance() {
        return instance;
    }
    
    protected SingletonClass() {
        procedure1();
    }

    protected void procedure1() {
        System.out.println("procedure1 called");
    }
}

    //in use, say, in the test harness
    SingletonClass instance = SingletonClass.getInstance();

Notice that the constructor is protected and cannot be accessed from outside the class. The only way to create the class is through getInstance and that returns the private static instance field created when the class is first referenced. Sub-classing and overriding has no effect, because the call to constructor happens as soon as the class gets referenced and the private static instance gets created. Mockito spies don’t work either for the same reason. Enter PowerMock.

PowerMock is a set of libraries used to extend existing mock libraries, such as EasyMock and Mockito to cover situations where it’s difficult to use them, such as static or final methods and constructors. In particular, the MemberModifier.replace method allows us to override methods (but only static ones) without instantiating the class.

    public static void replacement() {
        System.out.println("replacement");
    }
    
    public void testGetInstance() {
        //procedure1 has to be static to be replaced
        MemberModifier.replace(MemberModifier.method(SingletonClass.class,
                                                     "procedure1"))
                .with(MemberModifier.method(this.getClass(),
                                            "replacement"));
        SingletonClass result = SingletonClass.getInstance();
    }

It’s a bit brute-force, and with better design of the singleton class maybe unnecessary, but at least it can now be tested.

BDD and JBehave

I’ve been in my new job for a few weeks now and encountered Behavior Driven Development in the code I’m looking at, using JBehave.

BDD is a way of structuring unit tests in such a way as to make them more human-readable. Typically, a conventional unit test looks something like this (this is for a small builder class I’ve created):

@Test
public void testOneWhere() {
    //select with one criteria
    SQLBuilder instance = new SQLBuilder();
    instance.select().table("A_TABLE");
    String result = instance.where("A_COLUMN", "A_VALUE").build();
    assertTrue("result is not proper SQL: " + result,
            result.equals("SELECT * FROM A_TABLE 
                           WHERE A_COLUMN = \"A_VALUE\""));
}

This is quite a small test, but it’s easy to see that someone non-technical would have difficulty following what was going on here. Plus it’s not very flexible: if you want to test boundary conditions, for example, you either have to do a lot of cut-and-pasting or some fancy footwork with the test libraries.

Compare this to the equivalent BDD statement (called stories):

Scenario: with a where clause

Given a new SQLBuilder object
When select is called
And table is set to A_TABLE
And where is set to A_COLUMN equals A_VALUE
And build is called
Then the result is SELECT * FROM TABLE WHERE A_COLUMN = "A_VALUE"

This is supported in the test harness by methods bound to the statements in the story:

@When("select is called")
public void selectIsCalled() {
    sqlBuilder.select();
}

@When("table is set to $table")
public void tableSetToTable(String table){
    sqlBuilder.table(table);
} //etc.

Not only is the story more readable, but you can parameterise the calls, setting up tables of inputs and expected outputs. Nice.

It’s disdvantages seem to be that it does not have stories that can define throwing exceptions, but the idea is that exceptions should not occur at this level and should be handled lower down. Finer grain unit tests would probably handle this.

Introduction to Neo4j

Neo Technologies run little evening seminars to introduce their graph database technology and I took the liberty of attending one yesterday evening. You get a free book!

 

They’re based around the back of the Tate Modern, in an area which seems like an extension of Shoreditch with loads of start-ups and overpriced coffee.

It was a very interesting presentation, given by Rik Van Bruggen (Belgian), giving the background to the database and a really good demo using belgian beers as a dataset. Neo4j also has a community version that you can download as well as a free on-line course (with registration).

Rik also demonstrated a web site that visualises recommendations in Amazon.com, which is quite groovy.

The Graphs of Gaming and Recruitment

Yesterday evening, I went to a presentation on Graph Databases (specifically Neo4j, who were the organisers), hosted by Skills Matter.

First up was Nigel Small who talked about Zerograph, a new container/server for Neo4j.

Nigel gave a quick overview of Zerograph, highlighting it’s ability to host more than one database and the use of ZeroMQ (thus the name) to increase reliability and robustness. ZeroMQ is a message queue, which is a piece of software designed to buffer and schedule messages between two systems in a more controlled way than a direct connection. It also, in ZeroMQ’s case, allows for temporary disconnections, saving the messages to be processed when the connection is resumed. How this works in practise is another matter.

One of things emphasised throughout the talks was the speed with which Neo4j processes queries and returns results. Graph databases are designed to cope with information which is highly relational in nature, so something that in standard SQL would take seconds or even minutes with multiple joins, takes a fraction of that in a graph database.

Next up was Mark Wright to talk about the work at his company Stitched regarding the use of Neo4j in social networks for recruiting.

A quite amusing presentation, Mark illustrated the problems with existing social networks, such as Facebook and LinkedIn, and how “private” networks could be used to give more authentic results.

The last speaker was Yan Cui, from GamesSys, to talk about his experiences using Neo4j to model his company’s Freemium online game “Here Be Monsters“.

The game is resource based and can be incredibly complex and interrelated, so any small change in the underlying data can have considerable consequences. They’ve tried to make changes by rule-of-thumb, but this proved too unwieldy, slow and error-prone, so they’ve been modelling it with Neo4j and had much better results.

One of the things mentioned during the presentations was Cypher. Being interested in cryptography, I was a little baffled, but this turns out to be the Neo4j equivalent of SQL:

MATCH (n:Person)-[:KNOWS]->(m:Person) WHERE n.name="Alice"

Looks similar enough, although I can’t see why they didn’t call it Graph Query Language (GQL), which would be much more obvious.

Dependency Injection with Google Guice

One of the problems that we get in software development, specifically in the design of software classes, is that of the connection between classes. If one class uses another directly, even though it works, this can cause problems later on and is known as “close coupling”. Here is a mundane example:

//a really dumb message sending class
public class MessageSender {
    public void sendMessage(String message) {
        System.out.println(message);
    }
}

//another dumb class that uses the message sender
public class MessageUser {
    //a reference to the sender object
    private MessageSender messageSender;
    //the message sender object is created in the constructor
    public MessageUser() {
        this.messageSender = new MessageSender();
    }
    //send the message via the sender
    public void sendMessage(String message) {
        messageSender.sendMessage(message);
    }
}

//the main class that uses the message classes
public class MessageMain {
    public static void main(String[] args) {
        MessageUser messageUser = new MessageUser();
        messageUser.sendMessage("This is a test");
    }
}

OK, this is really mundane, but can see that MessageUser cannot use any other way of sending messages. If you want to use another means, say email, you’d have to either change what MessageSender does or change MessageUser to use a different class, call it EMailSender. However, we can now use an interface instead of a class:

public interface MessageSender {
    public void sendMessage(String message);
}

//an implementation of the interface
public class SystemMessageSender implements MessageSender {
    public void sendMessage(String message) {
        System.out.println(message);
    }
}

You still have to change MessageUser, but to use an interface given to, or “injected” into, the MessageUser object via the constructor:

public class MessageUser {
    //a reference to the interface
    private MessageSender messageSender;
    //the interface is sent to the object using the constructor
    public MessageUser(MessageSender messageSender) {
        this.messageSender = messageSender;
    }
    
    public void sendMessage(String message) {
        messageSender.sendMessage(message);
    }
}

This works if we then, in the main class, create the object that implements the MessageSender and pass it to, or inject it into, the MessageUser object:

public class MessageMain {
    public static void main(String[] args) {
        SystemMessageSender messageSender = new SystemMessageSender();
        MessageUser messageUser = new MessageUser(messageSender);
        messageUser.sendMessage("This is a test");
    }
}

Now if we want to have MessageUser send emails we create a class which also implements the MessageSend interface:

//an implementation of the interface
public class EMailMessageSender implements MessageSender {
    public void sendMessage(String message) {
        EMail.textMessage(message);
    }
}

All that then has to be done is create an object of this class in the main class and then pass it to MessageUser, as before:

        EMailMessageSender messageSender = new EMailMessageSender();
        MessageUser messageUser = new MessageUser(messageSender);
        messageUser.sendMessage("This is a test");

This technique, known as Dependency Injection, is quite an important design pattern and is mandatory in certain frameworks, such as Spring.

Introducing Google Guice

So far, so good, and it’s difficult to see how this can be really improved upon. However, Guice (pronounced with a J rather than a G) does for dependency injection what Mockito does for unit testing. To introduce Guice into the above example, we have to create another class, an extension of Guice’s AbstractModule class:

public class MessageModule extends AbstractModule {
    protected void configure() {
        bind(MessageSender.class).to(SystemMessageSender.class);
    }
}

You can sort-of see what’s going on. The module is responsible for creating the class that implements the interface, so whenever the interface is used, the object is bound to it. The magic happens in the Injector, used in the main class:

        Injector injector = Guice.createInjector(new MessageModule());
        MessageUser messageUser = injector.getInstance(MessageUser.class);
        messageUser.sendMessage("This is a test");

Notice that the module hasn’t been told about MessageUser, so the Injector is figuring out it’s dependencies from the constructor of the class, and this also has to change using the @Inject annotation:

    @Inject
    public MessageUser(MessageSender messageSender) {
        this.messageSender = messageSender;
    }

Now all this doesn’t seem like a big deal, if anything we’ve added lines and classes, but if now want to change it to send emails, all you have to do is change the Module:

public class MessageModule extends AbstractModule {
    protected void configure() {
        bind(MessageSender.class).to(EMailMessageSender.class);
    }
}

This concentrates the dependecy injection in one place, the module, which is acting as a sophisticated class factory. Guice is useful if you’ve got a lot of classes with umpteen dependencies and can save you a lot of work.

Mockito Spies

That is the collective noun, not the verb, although I suppose Mockito is spying…

Spies are used to make existing classes into Mockito classes. Say your class under test hooks into a Java listener, so you want some kind of dummy listener for it to hook into. You can’t do this with Mockito (at least I can’t find a way), but you can make your own:


//listener interface
public interface SomethingListener {
    //change that sends the event
    public void somethingChanged(EventObject e);
}

//our little dummy listener provider
public class DummyListenerProvider {

    private SwitchListener listener;

    //this is used by the class under test
    public void addSwitchListener(SwitchListener listener) {
        this.listener = listener;
    }

    //send event, saying the class is the source
    public void triggerEvent() {
        this.listener.somethingChanged(new EventObject(this));
    }

    //used by the event consumer when the event occurs
    public void switchMeOn(boolean isTrue) {
    }
}

Cool, but you still want all the nice little trinkets that come with the Mockito objects. This is where spies come in. You just wrapper the class using spy instead of mock:


DummyListenerProvider spyListenerProvider = spy(new DummyListenerProvider());

ClassUnderTest underTest = new ClassUnderTest(spyListenerProvider);

spyListenerProvider.triggerEvent();

verify(spyListenerProvider).switchMeOn(true);

Mockito – An Elegant Stub for a More Civilised Age

In software development, we make use of something called “stubs”. These are bits of code that don’t do anything at the moment, but allow us to continue coding elsewhere as if they do. They are also used in testing to substitute for more complex objects, and this is where “mocking” (creating “mock” objects) has been developed in object-oriented programming and test-driven development.

As an extension to the college work I’ve been doing, I’ve been looking into using mock libraries for unit testing and I’ve come across Mockito:

The mock objects it creates are, well, amazing to say the least. Say we’ve got an interface that, in turn, allows us to create a read I/O stream and a write I/O stream, for networking. The interface would look something like this:

//simple interface wrapper around a network socket
public interface MySocket {
    //creates a read I/O stream
    public BufferedReader getBufferedReader() throws IOException;
    //creates a write I/O stream
    public PrintWriter getPrintWriter() throws IOException;
    //indicates that a connection has been successfully made
    public boolean isConnected();
    //closes the connection
    public void close() throws IOException;
}

Now I can actually mock this interface with Mockito in the unit test:

import static org.mockito.Mockito.*;
...
MySocket socket = mock(MySocket.class);

You can now use this mock socket interface in whatever need the interface, so:

SocketThread socketThread = new SocketThread(socket);

Now, unfortunately, the mock doesn’t really do anything other than just record what happens to it. Say SocketThread calls socket.close internally when it runs:

//this is in SocketThread.run
socket.close();
...
//if this isn't true, you'll get an exception
verify(socket).close();

Useful, but it becomes a bit more powerful when we add mocks for the input and output streams:

PrintWriter printWriter = mock(PrintWriter.class);
BufferedReader bufferedReader = mock(BufferedReader.class);
when(socket.getBufferedReader()).thenReturn(bufferedReader);
when(socket.getPrintWriter()).thenReturn(printWriter);

You can control exactly what the mock does and when it does it. Very useful for unit testing (and I haven’t even begun to use all it’s capabilities).

Designing and Developing Reactive User Interfaces

This evening, I attended a presentation of an implementation of reactive technolologies in .Net by Lee Campell and Matt Barrett.

This centred around a trading application written by Lee, Matt and their team, and, perhaps, best to see this as a continuation of the presentation I saw last week at Microsoft. The application, which, they said, will be open sourced, was pretty slick, a combination of Windows Presentation Foundation and the original Microsoft Rx library. One of the things they emphasised was to see the design in terms of streams of information and events, rather than static entities and code.

It was a very good and well thought out presentation about an interesting, a prescient, subject.

Android Livecode, RxJava Architectures on Android at Microsoft

This was an Android Livecode presentation I attended, hosted at the Microsoft offices in sunny Westminster.

After the introduction, the main presentation was given by a Berliner, Timo Tuominen from Futurice, concerning the use of Functional Reactive programming on Android. This centred around the use of RxJava, an open source library based on a Microsoft library and implemented by Netflix, the video streaming company.

(A well attended presentation, as you can see, but there was free beer and pizza).

RxJava is centered around the use of an Observable class i.e. an implementation of the Observer design pattern from the “Gang of Four” book, on which most event model are based. It seems that the difference between, say, the standard Java listeners and RxJava is that the listeners have to be implemented within the class as you’re coding it. Here’s something I’ve been working on for the College:

//custom event maintenance
//this is a list of events that have to
//be serviced when something happens
private List<SwitchListener> listenerList = new ArrayList<SwitchListener>();

public void addSwitchListener(SwitchListener listener) {
    listenerList.add(listener);
}

public void removeSwitchListener(SwitchListener listener) {
    listenerList.remove(listener);
}

private void fireSwitchListener() {
    //parcel up the state of the switch in a SwitchEvent object
    SwitchEvent e = new SwitchEvent(this, isSwitchOn());
    //then send it to every listener in the list
    for(SwitchListener listener: listenerList) {
        listener.switchChange(e);
    }
}

Listeners are all over Java components as it provides a way of passing messages between the components and their containers without the components having references to the latter (a problem known as “coupling”).

What RxJava seems to do is wrapper up listeners, or something like them, into a framework that can be applied to any other object. For example, if you want to “listen” to an object so that when it changes you can do something else, or react to it, you can use the Observable class to do it:

Observable.from(names).subscribe(new Action1<String>() {
    public void call(String s) {
        System.out.println("Hello " + s + "!");
    }
});

It does seem to be something that you would think was already in function programming languages, like Clojure and Scala, by default, but RxJava can be used by these, so maybe it isn’t?

Java Concurrent Animated

I thought I take a trip into town this evening to see a presentation at Skills Matter by Victor Grazi (complete with “Brooklyn accent”) concerning Java concurrency.

Concurrency is always a difficult subject, but not so much the thing itself as what happens when concurrent processes try to access the same resources at the same time. Normally, in Java, this is done via the “synchronized” command. You designate a block of code and wrapper it in a synchronized block:

synchronized(this) {
    Counter.count++;
    System.out.print(Counter.count + "  ");
}

or declare a function to be synchronized:

public synchronized void assign(int i) {
    val = i;
}

However, if one thread gets to the block first, it locks out the any other threads trying to do the same. There’s nothing that the others can do about it other than wait.

Victor’s presentation was regarding what was available in the Java API, such as Locks, Semaphores, to get around this or avoid it altogether, as well as exploring other aspects of the API such as Thread Pooling.

What made this presentation a little different was the animation of the threads, which were doing little animated circuits to illustrate his points. The source can be found on SourceForge. It looks cute, plus is does show you the various options available to the Java programmer other than just the ubiquitous “synchronized”.

Overall, Victor gave a very good presentation of a difficult, but important, subject.