Thomas Sundberg

August 21, 2012

Separating tests in Maven

This post is available at


  1. Hi
    I’d suggest using failsafe plugin for integration/end2end tests and surefire for unit tests. I find this kind of separation very handy:
    failsafe provides hooks for starting/stopping external resources (like tomcat/jetty) and it runs all * test classes out-of-box. as surefire runs only * tests.

    Comment by miluch — August 22, 2012 @ 11:03

    • Hi!

      I would have used failsafe if I had a need for tearing down things after a failure. But that would have meant that I would have needed more setup. My goal with this blog was to justify my choice on how I usually separate unit and integration tests and I wanted as little configuration as possible.


      Comment by Thomas Sundberg — August 22, 2012 @ 15:05

  2. Thank’s for this handy article

    There is also another approach – use TestNG and it’s test groups feature.

    Then, you may categorise each test to specific group (e.x. UNIT, STATIC_ANALYSIS, INTEGRATION) and configure surefire plugin to have separated execution for each test.

    + No need to follow specific naming convention pattern for tests,
    + No need to put tests in specific packages
    + No need to build and install production code artifact prior to running integration tests (when using separated module for integration tests)

    – Need to use TestNG, buy for me it’s rather an advantage
    – Need to remember about adding groups=X to your @Test annotation, but it may be done by one test class which gathers all * files and checks for that.

    Code snippet for configuring maven-surefire-plugin:




    Then, you may specify another profile which can be enabled only on your CI machine:







    If you want to fallow this pattern you may also checkout Marcin’s blog:

    Comment by Matthew Grzechocinski — August 22, 2012 @ 12:41

    • Hi!

      We might not agree on the subject of TestNG 🙂

      But if the problem with separating fast and slow tests is easy to do using TestNG, then why not?


      Comment by Thomas Sundberg — August 22, 2012 @ 15:07

      • 🙂 My experience with TestNG (which I like very much, feature-wise) is that the separation is really easy: with TestNG all tests are slow – at least in Eclipse. It might be due to the TestNG runner/eclipse plugin, but it makes TestNG a nogo for me.

        Comment by Anonymous Coward — May 22, 2014 @ 14:38

      • I wouldn’t know anything about the performance in Eclipse. Life is too short for bad tooling so I use IntelliJ IDEA. The free version is great. If you can afford it, support the developers by buying the commercial version.

        Comment by Thomas Sundberg — May 22, 2014 @ 16:58

  3. Did you have misspelled include and exclude, in the first code example, in the execution element of integration-test ?

    Comment by yujiorama — January 23, 2013 @ 05:56

    • I don’t think so. The code in the example has been executed without any problems. I have a Maven plugin that reads my source code and then includes it into my text. I don’t do any retyping or cut and paste of the source code. What is the error you get when you try to execute it?


      Comment by Thomas Sundberg — January 23, 2013 @ 06:21

      • I have just only confused that the code “…” and “…”, but they worked correctly. Thank you for nice article.

        Comment by yujiorama — January 23, 2013 @ 06:42

  4. Hi!
    Thanks a lot for all your great articles!
    I just have a question about the pom.xml of the test module. According to the “Maven by example” book, which you referred to, a maven module should refer to its parent by means of a element. The pom.xml of your test module does not. Isn’t that an error?
    Best regards,
    Mikko Östlund

    Comment by Mikko Östlund — November 13, 2014 @ 01:28

    • Hi!

      It could be an error if you want the test module to be aware of a parent. In this case, I didn’t want the test module to be aware of any parent so I didn’t specify any parent.

      Specifying a parent is optional. A use case where you would like a module to be aware of its parents could be when you have a some common specifications that all modules should be aware of. A specific version of a dependency could be an example. In that case, you could have a dependency management section in the parent where you specify a dependency with version and in each sub module you just specify the dependency without version. This would allow you to update the version in one place and not many places.


      Comment by Thomas Sundberg — November 13, 2014 @ 07:17

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: