Category Archives: Testing

Skipping tests when doing “mvn install”

First things first: you should NOT be skipping tests when building your projects. 9 out of 10 cases, you shouldn’t. But when you must / have to / want to do it: after spiking what it looked like a quick solution to a little problem and it turned out to be a massive refactoring during which you broke so many tests it would not be worthy to fix them unless the original problem is really flushed away… possibly the most typical scenario where you would want to do something like this. Well, in that case, you can do:

mvn -DskipTests=true install

or the more lazy version:

mvn -DskipTests install

Or you can do:

mvn -Dmaven.skip.test=true install

or the more lazy version:

mvn -Dmaven.skip.test install

Difference between the first and the second is that the first one is less horrible. Let me explain… both versions will not run any of your tests classes, but at least the first one won’t succeed if they don’t compile. So, if you’ve broken your tests but at least you changed your source code well enough to maintain compilation errors away on your test classes, you can get away with the first command. But if you incurred in compilation errors on your test classes while changing your code, you may want to go for the second command, which not only it will ignore your tests but it won’t even attempt to compile the test classes.

If having to run the first command is already a sign that you’ve not been doing the important things (TDD, for instance) right, running the second means you can’t even use your IDE correctly (refactoring, anyone?).

[Learnt at work, from a colleague]

[Reference]

Eclipse template to insert test methods should-given-when-then

(originally posted on StackOverflow)
I saw a similar version to this one recently while pair programming with a very a good developer and friend, and I think it could be a nice addition to this list.

This template will create a new test method on a class, following the Given – When – Then approach from BDD paradigm on the comments, as a guide for structuring the code. It will start the method name with “should” and let you replace the rest of the dummy method name “CheckThisAndThat” with the best possible description of the test method responsibility. After filling the name, TAB will take you straight to the // Given section so you can start typing your preconditions.

I have it mapped to the three letters “tst”, with description “Test methods should-given-when-then” 😉

I hope you find it as useful as I did when I saw it:

@Test
public void should${CheckThisAndThat}() {
    Assert.fail("Not yet implemented");
    // Given
    ${cursor}

    // When

    // Then

}${:import(org.junit.Test, org.junit.Assert)}

About testing private methods

I’ve loved the next sentence, read here:

The more tests the more attention they need. We can reduce the time we spend on nurturing by writing test only against public method. Public methods are contract. If we specify some contract we will rather not change it as often as private methods. If you feel that you have to test private method it is a sign of a bad design (it’s called “code smell”). Probably functionality of this method belongs elsewhere.