Automatically loads Integration Tests into Junit Suite. Build for Integration Test execution performance and maintenance.
Switch branches/tags
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
sweet-junit-runner-examples-spring
sweet-junit-runner
.gitignore
.travis.yml
LICENSE
README.adoc

README.adoc

Build Status Test Coverage Test Coverage

sweet-junit-runner

The sweet junit runner allows to dynamically load test classes into junit Suites.

The problem to solve

The maintenance of integration tests is a difficult and time consuming process.

In a Spring managed environment for example, each integration test starts the spring container before the test execution and destroys it when the test is finished. This is a very time consuming process, especially if there are dozens of test cases.

To solve the problem you can group your tests into junit Suites like this:

@RunWith(Suite.class)
@Suite.SuiteClasses({
   TestJunit1.class,
   TestJunit2.class
})

public class JunitTestSuite {
}

As you can see, this solution requires you to hard code the test classes in the JunitTestSuite in order to execute them. If one writes another test and forgets to add it to the SuiteClasses list, the test will not be executed.

Usage

Using annotations

The sweet-junit-runner allows to dynamically load test classes annotated with @IntegrationTest or @SuiteTest into a JUnit Suite as follows:

@IntegrationTest
public class IntegrationTestToLoadTest {

    @Test
    public void testMe() {
        System.out.println("I was here!");
    }

}

@SuiteTest
public class UnitTestToLoadTest {

    @Test
    public void testMe() {
        System.out.println("I was here!");
    }

}
@RunWith(SuiteRunner.class)
@SuiteConfiguration("org.codelamb.sweet")
public class IntegrationTestSuite {
}

Note that you have to provide a SuiteConfiguration to tell the runner where to search for the classes that have to be loaded:

In the previous example the

  • org.codelamb.sweet.TestJunit1 - would be loaded

  • org.codelamb.sweet.sample.TestJunit2 - would be loaded

  • org.codelamb.TestJunit3 - would NOT be loaded

This way one can assign different test classes to different junit Suites.

Using a pattern

If you do not want to annotate all your test-classes its possible to use a pattern which will load all classes that match this pattern.

@RunWith(SuiteRunner.class)
@SuiteConfiguration(value = "org.codelamb.sweet", containsFilter = "Test")
public class IntegrationTestSuite {
}

In the previous example the

  • org.codelamb.sweet.TestJunit1 - would be loaded (because of its annotated)

  • org.codelamb.sweet.sample.TestJunit2 - would be loaded (because of its annotated)

  • org.codelamb.TestJunit3 - would be be loaded (because it matches containsFilter)

Maven integration

The maven-surefire-plugin allows to execute Suites. For example:

<profiles>
  <profile>
  	<id>integration-tests</id>
  	<build>
  	  <plugins>
  	  	<plugin>
  	  	  <groupId>org.apache.maven.plugins</groupId>
  	  	  <artifactId>maven-surefire-plugin</artifactId>
  	  	  <executions>
  	  	  	<execution>
  	  	  	  <id>integration-tests</id>
  	  	  	  <phase>integration-test</phase>
  	  	  	  <goals>
  	  	  	  	<goal>test</goal>
  	  	  	  </goals>
  	  	  	  <configuration>
  	  	  	  	<includes>
  	  	  	  	  <include>**/*Suite.java</include>
  	  	  	  	</includes>
  	  	  	  </configuration>
  	  	  	</execution>
  	  	  </executions>
  	  	</plugin>
  	  </plugins>
  	</build>
  </profile>
</profiles>

Future ideas

Extended configuration

Allow loading test classes based on naming pattern as an alternative for @IntegrationTest annotation

Preconditions

Add Preconditions to simplify the maintenance of integration test

  • integration test can be linked to a precondition

  • preconditions will be checked before the test are executed

  • the integration test will not be executed when the precondition test fails

Use case

20 out of 50 Integration tests depend on a Database connection. If the Database is down, the 20 Tests will not be executed. The precondition test will be failing with a proper explanation.