Parameterized JUnit test

Today I needed to do a quick test for a custom NameUtils class that capitalized human and business names based on some very specific rules. To do that I decided that the best way is to use a Parameterized JUnit test and the best and fastest way of doing it is by using Junit with JUnitParams. This project adds a new runner to JUnit and provides much easier and readable parameterized tests for JUnit >=4.6. According to their own JUnitParams homepage the main differences to standard JUnit Parameterized runner are:

  • more explicit – params are in test method params, not class fields
  • less code – you don’t need a constructor to set up parameters
  • you can mix parameterised with non-parameterised methods in one class
  • params can be passed as a CSV string or from a parameters provider class
  • parameters provider class can have as many parameters providing methods as you want, so that you can group different cases
  • you can have a test method that provides parameters (no external classes or statics anymore)
  • you can see actual parameter values in your IDE (in JUnit’s Prameterized it’s only consecutive numbers of parameters)

So first, since we are using maven, then we need our dependencies:


While JUnit is very common, JunitParams is probably not so popular yet. It’s a package of small helper annotations that allow you to better write your tests.

So now – what are these parametrized tests I’m talking about? Here’s a quick example:

import static org.junit.Assert.assertEquals;
import junitparams.FileParameters;
import junitparams.JUnitParamsRunner;

import org.junit.Test;
import org.junit.runner.RunWith;

public class NameUtilsTest {

	public void testNameCapitalization(String input, String expected) {
		assertEquals(expected, NameUtils.capitalize(input));


This test asserts that our NameUtils.capitalize method returns expected results.
As you can see, we use @RunWith that tells JUnit to this test using JUnitParamsRunner and then we use @FileParameters that tells junit to run this test once for every single line in that CSV file.

On each of the CSV file lines we have our input and expected output, like this:

john doe, 					John Doe
DR. JOHN DOE, 				Dr. John Doe
ACME Corporation Ltd.,		Acme Corporation Ltd.
Miriam Torrence, 			Miriam Torrence
Shawanna Melody, 			Shawanna Melody
    SPACE     Tuma, 		Space Tuma
Jeraldine Ownbey, 			Jeraldine Ownbey
Nilda Cavaliere, 			Nilda Cavaliere
bUffy Yearta, 				Buffy Yearta,
AMANDA skoog, 				Amanda Skoog
a,							A
a b			, 				A B
Elias johnny cash Rash,		Elias Johnny Cash Rash

And now when we run our code, we get:
parameterized junit test results

Note that the test was ran for every single line in that CSV file and this allows you to quickly add new cases or testing material to constantly improve your code verifications.

If you have a question or having trouble getting it to work on your machine then feel free to write in the comment section and I’ll do my best to help you out. If you would like to read more about Unit Testing related subjects then also make sure to comment on that and if you liked what you read then make sure to subscribe – It’s FREE!

Jenkins and Maven Release plugin

OK, So here’s a quick tutorial on how to make a Jenkins and Maven Release plugin build that automatically creates a release build using Jenkins and we are assuming your code is in Git.

Step 1 is easy, get your code from Git. You just configure the Jenkins build as always.

Now, We need one additional plugin for Jenkins which is “Workspace Cleanup Plugin”. This allows us to enable
“Delete workspace before build starts” in Build Environment section.

Now the tricky part: Under Pre Steps you must add a new shell command:

git checkout master

This is because otherwise your git is checked out without a specific branch and maven release plugin will fail.

Build command

-B -Dusername=jenkins -Dpassword=JenkinsPasswordForGit release:prepare release:perform

Important notice – you can configure jenkins user to have automatic access to git in other ways also, but I decided to keep this info in the build.

Once you start releasing your project with Jenkins, you quickly discover that manually managing the version numbers inside your own multi-module project will become a hassle. Simple solution would be to configure Jenkins to upgrade your own dependencies to the latest releases (requires you to limit versions plugin to your own packages):

-B versions:use-latest-releases scm:checkin -Dmessage=$BUILD_NUMBER -Dusername=jenkins -Dpassword=JenkinsPasswordForGit release:prepare release:perform

Now we might want to limit versions plugin to our own com.codeyouneed package since having it upgrade ALL dependencies all the time is really bad.


Now that’s pretty much it. That git checkout master command took me a while to figure out.

Of course, for maven release plugin to work you actually need to add some stuff to your pom.xml also:



Important notice if you are dealing with multi-module maven projects – Submodules have to leave out their name from scm.url since release plugin will add the name by itself into the end of the URL.


So you should leave out the “/submodulename”.

Special thanks to a blog post that lead me to the right path:

Jenkins Logo