Maven Surefire + Failsafe, the easiest way

Tell me I’m not the only one. Your web application has a bunch of unit tests, and Cobertura says all kinds of nice things about your coverage. But every now and then you check something in and the build breaks. But it worked locally, so what the hell?

mavenThen you realize that one of the tests depends on a REST call to some other system, and they changed their data. In other words, you realize that you, my friend, have a mix of unit tests and integration tests.

Don’t panic. Just add the Maven Failsafe plugin to your build. Failsafe is similar to the default testing plugin that you already know and love: Surefire. But it’s specifically made to run integration tests. There’s a lot of great documentation, but I hope this example will get you up and running faster than I did.

Step one: add the Failsafe plugin to your pom

[code lang=”xml”]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.17</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[/code]

Unfortunately, the Failsafe plugin doesn’t come out of the box like Surefire does so you have to explicitly add it to your build.

Step two: separate your unit and integration tests by convention

By default, the Surefire plugin will pick up any classes named *Test.java or *TestCase.java. By contrast, Failsafe picks up any classes named *IT.java. That’s nice because you can let them coexist in the same src/test/java folder.

src-test

Just for reference, here’s my “code” for the Demo tests:

[code lang=”java”]
public class DemoTest {
@Test
public void test() {
System.out.println("Hi. I’m a unit test.");
}
}
[/code]

 

[code lang=”java”]
public class DemoIT {
@Test
public void test() {
System.out.println("And I’m an integration test. Can’t you tell?");
}
}
[/code]

Step three: run mvn verify and check the output

The verify life cycle runs both test and the integration tests (check the documentation for a lot of important detail):

mvn-verify

You’ll see it run the normal unit tests:

demotest

And then it runs again for the integration tests:

demoit

As to how you’re going to integrate this life cycle into Jenkins, Bamboo, or whatever — I’ll leave that up to you! Good luck out there and let me know how it goes.

“Imperative code should be your default, your first choice as of Java 7”

Let’s say you’re not at Java 8 yet, you’re still learning how to spell l-a-m-b-d-a (see? I did it), and yet you still want to get into this functional programming “thing.” But let’s also stipulate that you know and love Guava.

Even though the Guava team cautions that “functional programming in Java can only be approximated through awkward and verbose use of anonymous classes,” you know that the Guava folks have also tempted and taunted you by creating a number of classes and interfaces that look an awful lot like Java 8’s new functional interfaces (see, e.g., Predicate and Function). Resistance is futile, you remind yourself.

So you create something like this:

[code lang=”java”]
public void whatever() {
class Student {
final String firstName;
final String lastName;
public Student(String firstName, String lastName) {
this.firstName=firstName;
this.lastName=lastName;
}
}
ImmutableSet<Student> students = ImmutableSet.of(
new Student("James", "Jones"),
new Student("Neil", "Sanders"),
new Student("Michael", "Rice"),
new Student("Michael", "Shore"));
Iterable<Student> michaels = Iterables.filter(students, new Predicate<Student>() {
@Override public boolean apply(Student input) {
return StringUtils.equalsIgnoreCase(input.firstName, "michael");
}
});
for (Student michael : michaels) {
System.out.println(michael.lastName);
}
}
[/code]

Looks kind of slick and kind of functional, huh? Looks like it gets you a few steps closer to Java 8, right? But then you’ve got a comment something like the following from the Guava team: why don’t you just loop through them? That’s easier to read, isn’t it? They say the following is more virtuous (at least for Java 7 and older) — largely because it takes fewer lines of code and because it’s more readable:

[code lang=”java”]
// …
Set<Student> michaels = new HashSet<Student>();
for (Student candidate : students) {
if (StringUtils.equalsIgnoreCase(candidate.lastName, "rice"))
michaels.add(candidate);
}
// …
[/code]

In fact, the Guava folks go so far as to say:

Please be sure, when using Guava’s functional utilities, that the traditional imperative way of doing things isn’t more readable. Try writing it out. Was that so bad? Was that more readable than the preposterously awkward functional approach you were about to try?

The Guava folks are really thoughtful about the code, so I have no issue with their comment except that they’ve missed an important psychological component. They missed the fact that it’s so much fun.

The simplest Gradle example I can come up with

gradleI’m just now getting into Gradle, and I had a little trouble just Googling a simple build script that would get me up and running with a basic Spring MVC web application quickly.

In case you’re looking for the same, here’s what I came up with:

[code lang=”groovy”]
apply plugin: ‘war’
apply plugin: ‘jetty’

sourceCompatibility = 1.6
version = ‘1.0’

repositories {
mavenCentral()
}

dependencies {
providedCompile ‘javax.servlet:servlet-api:2.5’
compile (‘org.springframework:spring-webmvc:3.2.2.RELEASE’,’javax.servlet:jstl:1.2′)
testCompile (‘junit:junit:4.11’, ‘org.springframework:spring-test:3.2.2.RELEASE’)
}

jettyRunWar.contextPath = ”
[/code]

For the record, I’m only focusing on Spring because that’s what I work on most of the time these days.

  • The first section declares plugins. I think this declaration block is quite a bit more expressive than Maven, where you have to declare plugins at various points in the pom.xml in a really verbose way. With Gradle, it’s pretty simple (query if I’m losing power?): you can quickly tell from my script that I want to package the project as a war (for Tomcat/servlet container deployment) and that I want to be able to run Jetty locally to test it.
  • Next, similar to Maven, Gradle needs access to a repository of artifacts. Gradle gives you access to the Maven Central Repository by declaring mavenCentral() as a repository. It’s definitely easier to read than a pom, but again, query whether I’m losing some configuration power here.
  • Finally, we need to declare our dependencies. If you understand the Maven coordinate scheme, then Gradle is a little easier than the verbose pom.xml. Plus it’s easier to see what dependencies go into what build cycle. For example, I’m declaring the servlet API at compile time, but I’m not declaring JSTL or Spring MVC until the actual compilation (yes, yes, I know my Spring MVC is a little out of date). NOTE: it seems like Intellij got the dependency wrong when it created my initial gradle file. The JSTL dependency actually needs to be bundled into the WAR to get the “newer” JSTL syntax.

So there you go, it’s not that different from Maven:

  1. Tell Gradle what plugins you want to run.
  2. Tell it where to get its artifacts.
  3. Tell it what artifacts you want.
  4. Save it as build.gradle and then run gradle tasks to see what you can do with it.

Good luck out there.

Debug deep dive into doDispatch() in Spring MVC

I’ve been stuck at home with sick kids so I just decided to take a debugging deep dive into the doDispatch() method of Spring MVC’s dispatcher servlet (DispatchServlet, the so-called “front controller“). Since this is my blog and I get to write whatever I want no matter how trivial, I thought I’d share two impressions, each of which are informed by a lack of sleep.

One impression: is Spring’s strength also its weakness?

I think of Spring as coming of age in era of enterprise Java when many competing frameworks were trying to be all things to all people. Spring beat J2EE in some early battles because it successfully appealed to all audiences while not imposing too much heavyweight configuration for most enterprise developers, which probably comes as a surprise to new today’s new developers. These days, developers are either annoyed or intimidated by its flexibility.

Its flexibility remains awesome, however. As an application developer, you can customize a HandlerMapping object, HandlerAdapter, HandlerExceptionResolver, ViewResolver, LocaleResolver, LocaleContextResolver, ThemeResolver, MultipartResolver, and a FlashMapManager. Just take a look at the DispatchServlet itself. It invokes the strategy pattern to use stategy objects on nine major configuration options:

Some of this annoyance and intimidation (and of course, I get both annoyed and intimidated too) comes from Spring’s impenetrable naming scheme. In its pursuit of being all things to all web developers, something like HandlerAdapter is so vague that it’s meaningless the first time you see it. And that’s easy compared to something like DelegatingFilterProxy or SerlvetInvocableHandlerMethod (which is a class, BTW). Spring has precise, but intricate and opaque (to the average developer) naming conventions.

So I guess my point on this impression is that I wish there was something like Spring Lite MVC that didn’t make me think about all these configuration options; I’m thinking of a light implementation that simply let me write some @RequestMapping decorated classes and some JSPs and call it a day. If I want to go further, I will.

Maybe Spring Boot will cure my worries, but is it too “opinionated” to build a simple MVC-CRUD-based web app without learning what the Spring folks’ “opinion” is?

Second impression: is Spring’s flexibility leaving optimization on the table?

Obviously, flexibility implies (requires?) a performance trade off. And if you’ve worked with Spring MVC, you know that a big part of its power is its ability to resolve a web request to @RequestMapping annotations you’ve used to decorate your controllers–without having to write XML. What you might not realize is (a) how deep in the stack trace you are and (b) that Spring MVC performs as if it’s the first time it’s ever seen your application for every single request. The first problem comes from Spring’s verbosity and their designers’ OO elegance. I’ll defer that issue to them.

It seems to me that the second issue could be solved with a little real world caching though. In mapping a simple request, say to “/” from a web browser, Spring MVC goes through a fairly tortured and exhaustive reflection-informed search of all annotations of all your classes for the right @RequestMapping mapping to a given request — every time! While that might only be a few dozen or a few hundred loops in any given Spring MVC solution, it still seems wasteful to me. Wouldn’t a simple @Cacheable annotation fix this — at least in part? Of course, if I’ve overlooked something and I’m wrong on this point, please let me know!

IRC cheat sheet

I’ve been trying to spend more time on IRC because if feels like I’m close to the bare metal, even if I’m actually just helping some computer science student do his homework. However, I’m kind of embarrassed to say that I don’t remember all the IRC commands I used to know way back when. In fact, I’m a little disappointed that I didn’t find a let’s-get-back-to-internet-basics-and-off-the-proprietary-web-like-Twitter flight to IRC.

Since I unequivocally lack the time or the persona to spark any IRC 2.0 movements, here’s just a quick cheat sheet for the few moments I do have to be on IRC on any given day. I’m /michaelrice on Freenode, BTW; when I’m on, I’m always in the #java channel.

/join #<channel> – duh, even twenty years won’t let you forget that one.

/me <does something witty> – as in, “/me rolls his eyes” will show up as *michaelrice rolls his eyes

/ignore <nickname> – for that defamatory harasser that you can’t find a proper jurisdiction to initiate suit for or ask a judge for a TRO; yeah, that guy (or girl, but that’s not a problem I personally have out there on the net, especially on IRC, but I thought I should write it down just in case)

/msg NickServ IDENTIFY <password> – when you have a registered nick, like I do, you send your password to “login” with this command. Luckily, Freenode will remind you how to do this when you first logon:

nickserv-password

UPDATE: As I spent some time on the #freenode channel, I put this on Twitter:

real-internet-is-irc

Sometimes I think it’s the little things like this

… that contribute to people thinking that Java is your dad’s (or mom’s) language of choice. This is the link to subscribe to Java Magazine (trademark designation and all).

javamagazine-subscription

I.e., why would I have to say I want to subscribe when I clearly clicked on some call to action link that said, “Subscribe to Java Magazine.” I won’t even talk about the fact that the Oracle link provided by a YouTube video published yesterday has the wrong link. Or maybe I just did. Whatever.

Do you ever think that it’s time to take the Java VM and language out of Oracle and the JCP’s hands?