iPROFS Technology Blog

In a few other posts on this blog I talked about the importance of unit testing and Test-Driven Development (TDD).

TDD helps us to ensure we’ve covered everything in our system by tests. Sure thing if you never write more production code than to satisfy a failing test, you’ve always covered all your production code by tests.

But how do we write a good suite of tests? How do we ensure that our tests help us maintaining the system? And remember, in agile development maintenance starts after the first successful compilation. Read more…

Recently, I attended a talk titled ‘the Well-grounded Java Developer’, at Devoxx ’11. The authors of the similarly named book convinced me once more that the java.util.concurrent package in the JDK contains a lot of useful classes and concepts that deserve a closer look. The package should definitely keep you from re-inventing the wheel.

Thus, it reminded me of how we put a CountdownLatch to actual use in a recent project.
In this post we will show you how.

Read more…

Introduction.

Just like everything in the software industry: You need to make sure that your knowledge and your tools stay up to date.
New developments and new additional framework could make your life easier.

I previously wrote about ‘How we do unit testing with junit and mockito‘.
Recently I started using the Matchers from Hamcrest for writing my test expressions.
That library allows us to specify the requirements in a syntax which almost read like normal english. I just really like things like this:

String message = messageBuilder.getMessage();
assertThat(message, is(equalTo("This message will self destruct in T-10")));

Or this:

List allLetters = AlphabetGenerator.getAllLowerCaseLetters();
assertThat(allLetters, hasItems('a', 'e', 'i', 'o', 'u'));

Tool configuration.

Maven.

In order to use all the libraries in your maven project, you need to have the following dependencies with scope test:

<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>4.8.2</version>
	<scope>test</scope>
</dependency>

<dependency>
	<groupId>org.hamcrest</groupId>
	<artifactId>hamcrest-library</artifactId>
	<version>1.2.1</version>
	<scope>test</scope>
</dependency>

<dependency>
	<groupId>org.mockito</groupId>
	<artifactId>mockito-all</artifactId>
	<version>1.8.5</version>
	<scope>test</scope>
</dependency>

Eclipse.

Since the syntax of the test expression changes, so should the favorites in your IDE.
My list of favorites has been changed to:

• org.hamcrest.MatcherAssert
• org.hamcrest.Matchers
• org.mockito.Mockito

In my previous blog I showed the use of JUnit categories and found that running them though a suite on which all test classes must be specified is a bit clunky. After a bit of experimenting I found a way to have a single suite that includes all test classes from the classpath, and using this suite in the specific category suites.
Read more…

In your build process you want fast running tests to provide whatever feedback they can very quickly. A way to organize this is to group your tests by distinguishing between the fast unit tests and the slower tests such as integration, performance, and load tests. TestNG already supports this, and now with its 4.8 release JUnit catches up with a feature called Categories.
Read more…

JRebel, also known in the past as java-rebel, is a class reloading tool, that will automatically reload your classes when you change anything in it. And with anything, I mean anything (well almost anything, but the exceptions will follow shortly).

Normal hot-swapping containers can also reload classes in some occasions, but those occasions are limited to the content of existing methods (and for a number of times. After a couple of times of reloading classes in tomcat, you might or might not start to see different results then you are expecting). JRebel however can reload many more situations, for instance when methods are added or removed, or when the signature of the method is changed. In all of these situations JRebel can reload your classes without requiring a restart of the container. And that is a huge time safer.

There are some exceptions to the reloading though, static final Objects that are part of other classes will not be reloaded of course, since they are already done loading. An exception to this rule is the reloading of final Strings. These will be reloaded by the JRebel class loader.

For instance, given the following code in a spring web mvc controller, called ExampleController:

public static final String COMMAND_NAME = "commandd";

your web page will most likely not find this command, since the name should have been ‘command’ without the double ‘d’ character.
Now, if you rename the content of the COMMAND_NAME to “command”, JRebel will kick in and tell us:


JRebel: Reloading class 'ExampleController'.
JRebel-Spring: Reconfiguring bean 'exampleForm' [ExampleController]

And now your page (using the command object by the name “command”) will display correctly. You just saved yourself a restart of the container.

Of course, this should have been captured during a JUnit test, but JUnit-testing of webpages is not always the best option to build a web application.

Even annotations (not all of them) can be hot-swappable by JRebel. For instance, if in the same controller we have a method, defined as:


@RequestMapping(value = "/user/addExample.html", method = RequestMethod.GET)
public ModelAndView addExample(final HttpServletRequest request) {
...
}

and we decide that this method should be handled by the superuser from now on, and thus the url should be changed, then that is no problem either for JRebel. Just change it to the new url and it will be available for your application.

If we had changed the name of the method as well, then this too would have been reloaded without any issues.

All these small kind of refactorings each day can add up to a lot of restarts of the container, and if all these restarts are not required anymore then the coffee-corner-team will start to miss you. According to the JRebel website, the time saved can be from 10 to 23 procent.

The only downside I can see at the moment is that JRebel is not free or open source and that you have to buy an annual description. But this will be worth it in the end, you just have to try to convince the ‘powers that be’ to spend some cash on this tool. If you want to start programming in Scala (and who wouldn’t want that these days) then you can get a scala license for free for a year. (See Scala license for free ). It is also possible to try JRebel for free for 30 days, but afterwards you are stuck with the ‘powers that be’ again.

Lately I’ve been spending some time on Java EE 6. While it’s stack looks fine and seem even usable this time, one of the things to overcome is integration testing.

Working on a Spring 3.0 project myself, integration testing is simply a matter of setting up a Spring container with test configuration using Spring’s test integration. Wondering around how to accomplish integration testing in Java EE I came across Arquillian.

Arquillian provides a framework that allows running tests in a container, while taking away container lifecycle and deployment. Arquillian supports most popular containers, like JBoss AS and Glassfish, both embedded and remote. The framework integrates with JUnit and TestNG. And if you’re not on a Java EE container, Arquillian supports both Tomcat and Jetty too.
Read more…