Spring Testing

This entry contains necessary information about Testing with Spring. One of the most interesting feature of the Spring Framework is the use of lightweight containers which simplify the testing of an application, whether the usual J2EE container can be more cumbersome to test.

Since there are so many aspects in Spring, I should first present a given overview of the different topics.

Dao Testing

Spring provides different mechanism to simplify testing. In particular there is a class to perform Dao testing by including the transactional aspects. You can easily load your daos using a xml file to initialize the configurations of the database and daos.

NOTE to myself: I hsould give here a code example.

Controller Testing

Here again Spring controller are quite easy to test. They require very little overhead. And the dependency injection provide a very simple setup.

GWT, SmartGWT and Testing

Automated testing is very useful, and would be even more useful, if it was much more easy. It seems though that the testing frameworks for web application as still not yet part of the tool box of web application developpers.

I hope this will help me to implement automated testing of web application.

I did some research on testing of GWT. It seems that it is possible to use selenium for GWT and for smart gwt. I must really get to this quickly.

Mockito - basics

This entry gives simple methods on how to use mockito.

Maven configuration

To add mockito-core to your configuration, update your dependencies with:

<!-- needs extra dependencies: objenesis & hamcrest -->
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>1.8.1</version>

In order to add the complete mockito framework, i.e. mockito-all, update your dependencies with

<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.8.1</version>

Of course if the mock code is only found in unit tests, then you might want to add:

<scope>test<scope>

to your pom.xml

Use of Mocks to verify interaction (Spying)

The following example is adapted from the mockito documentation

// the staic import allows the direct use of the help methods: mock and verify
import static org.mockito.Mockito.*;

// create a mock of a map
List mockedMap = mock(Map.class);

//using mock object
mockedMap.put("key", "value");
mockedMap.clear();
//verification
verify(mockedMap).put("key","value");
verify(mockedMap).clear();

Stubbing - Or Have your objects mock others

While the previous section was used to verify that some operation did occur on a specific object. In some cases, you may not wish to initialize completely a complex object. In such a case, you can use mockito to perform stubbing, i.e. mockito provides an interface, so that the object returns a specific value, when a call to a method is performed.

For instance, it is possible to use the mocking framework to return a given result for certain parameters:

when(mockedMap.get("key")).thenReturn("first");
when(mockedList.get(5)).thenThrow(new RuntimeException());

Mock Frameworks

In this entry, I present a summary of the features of mock frameworks. In particular, I looked at two different mock frameworks: easyMock (MIT Licence), Mockito (Apache Licence) and JMock (probably equivalent to BSD, MIT or Apache but I am not completely sure). The Mockito framework seems to be trying to extend even more the features of the easy mock.

Usual Use Cases of Mock Objects

I adapted the following list from a wikipedia entry. It shows the cases where it a good practice to use mocks.

• results of method do not follow a very deterministic pattern
• The mock can simulate a complex object or an object difficult to obtain, e.g a given state in a GUI
• A state of a system which is expensive to create, resource, processing, power...
• The object has not yet been provided, perhaps by an other team

Here are some useful posts on mocks:

• Mocks, Fakes, Stubs and Dummies , Gerard Meszaros explaining the different type of test doubles.
• Let's Spy
• Mocks and Stubs aren't Spies

I notice this post is not at all too clean. It needs to explain the purpose of spying and the difference there is with mock objects which are only dummy object or fake object.

Autotest - WOW they did it!!!!

Welll I was reading as always a little bit of this automated testing approach. And I was again on this page: http://autotest.kernel.org/ Autotest is a software which allows the automated testing of the linux kernel, that is, it is an infrastructure to build, boot and ... linux kernels. It has quite a lot of features:

• bisection...
• building
• booting
• filesystem check
• python based library to automate scripts

There is a good presentation on autotest presentation.

Differences between JUnit 3.8 and JUnit 4

There is a number of changes between these two versions of JUnit. For backward compability. Old Test method should still work I believe. I will sum up which are the features which changed. package names: version 3.8 used the junit.framework packages whereas 4.0 uses org.junit packages. Inheritance: the Test classes do not have to inherit from TestCase anymore. However, the new JUnit approach makes a stronger use of annotations. Assert changes: In order to use asserts with JUnit, you can either use the Assert.assertEqual(...) ( or similar methods) or import staticly the Assert class ( from Java 1.5 on) using:

import static org.junit.Assert.*;

in the import section of your test file.

Moreover, from JUnit 4.0 on there are also  method to compare arrays of objects.

Initialisation and cleaning:

The initialisation and cleaning were performed using setUp() and tearDown() methods. In version 4.0,
it is not possible anymore since the class does not extend TestCase. To solve this, new Annotations are
used: @Before and @After.

Note that there are also the annotations: @BeforeClass and @AfterClass which are the methods which
are called before loading the class for test and after all the tests have been performed.

Tests

Tests are annotated using the @Test annotation and must also return void and may not have any parameters.
These properties are checked at runtime and issue exceptions if these rules are not respected.

Ignoring Tests
It is possible to ignore a given test by using the @Ignore annotation before or after the @Test annotation


Performing Test

One performs test using the following call:
$ java –ea org.junit.runner.JUnitCore 

where  is the java complete name of the test class.

Timeouts

It is also possible to use a Timeout parameter for the test methods

Parametrised Tests

It is also possible to apply the same test but with different parameters. For this, the annotation
@Parameters may be used together with the class annotation @RunWith(Parameterized.class)

Suite

Like for the preceding version, there is also the possibility to use Suites of Tests. For this the
annotations @RunWith(Suite.class) and @Suite.SuiteClasses({FirstTestClass.class, SecondTestClass.class})

The article I used to write this entry states the lack of support in IDE for the new JUnit 4.0 version. But I suppose
that this changed in the latest versions of eclipse.