Run one or Exclude one test with Gradle

From time to time you only want to run one test, one test method, one class or one package from the command-line.

Or on the contrary: you want to exclude / ignore one specific test or group of tests during the build cycle.

Excluding tests from the build cycle by the command line usually occurs when the following scenarios meet:

  • A test requires significant amount of resources (time, memory, disk space, etc.)
  • The run needs to be independent from the IDE (to reenact the Continuous Integration / Continuous Delivery pipeline) as some IDEs load test-dependencies on the compile-time class-path.
  • You have no or limited ability to change the code-base

Continue reading

Implementing architectural fitness functions using Gradle, JUnit and code-assert

Architectural fitness functions

Inspired by Neal Ford’s presentation at our Change is the Only constant event I started experimenting with architectural fitness functions. An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).

If you want to take a deeper dive into evolutionary architectures including fitness functions take look at Neals book: Building Evolutionary Architectures: Support Constant Change.

Neal’s slides contained an example of verifying package dependencies from a Unit Test using JDepend.


Verifying code modularity

In this blog post we’ll elaborate on that approach and create a Unit Test that verifies that our code complies to the chosen packaging strategies using an alternative to JDepend named code-assert.

Continue reading

Nifty JUnit : Using Rule on Method and Class level

As shown in a the post Nifty JUnit : Working with temporary files, it is possible to use @Rule in a JUnit test, which is a Method level Rule. In this example I would like to show the variation of the @ClassRule for a Class level Rule.

Method Rule

The @Rule is fired before each test method (just like @Before) and after each test method (just like @After) of the test class, as shown in the example below.

Class Rule

Besides the regular @Rule we have the possibility to create a @ClassRule. In the example of the TemporaryFolder it will result in a folder which is created before all test methods (just like @BeforeClass) and destroyed after all test methods (just like @AfterClass). In the example below you can create a temporary file and use the exact same file in all the test methods. The temporary file will be deleted when all the test methods are finished.

Nifty JUnit : Working with temporary files

I get this question quite often and I struggled with it many times before: How do I work with temporary files in my JUnit testcases? I would like to explain two simple ways of working with temporary files in JUnit.

1. DeleteOnExit

Create a temporary file with the Java File API and mark it directly as deleteOnExit(). The created file will be deleted when the JVM exits.

2. TemporaryFolder Rule

Use the TemporaryFolder as a Rule in your JUnit Test. TemporaryFolder is an existing Rule from JUnit, see documentation here. The Rule will fire a create() before each test method, which creates a temporary directory. After each test method a delete() method is fired, which deletes the folder and all created files recursively.