The latest expert opinions, articles, and guides for the Java professional.

Is your TDD slow? It doesn’t have to be that way!

This post was modified from its original version, we’ve rewritten it to be more precise and updated it with the fresh information.

TDD Slow

The term putting the cart before the horse is a fairly easy to understand the analogy that means we’re doing things in the wrong order. The cart here can’t pull the horse; that just wouldn’t work unless the cart were motorized. I guess the horse could push the cart, but it makes everything a lot harder as the image above shows (although that seems to be working!). Anyway, we’re already getting off topic. Test Driven Development, or TDD, makes us question which is the horse and which is the cart. Is the development our horse or the testing? Historically, it was a given that we would develop our code first, and tests would (sometimes) follow, but in the modern age TDD is an accepted and exercised practice where a developer would understand the functional behaviour of a given function or class and write tests first that enforces that behaviour. Once the bounds of the new code have been put into place, a developer can safely code with a happier feeling that their development code will match the brief expected of it. So which is the horse? Well, it depends if you follow TDD practices or not!

There are numerous libraries and tools for writing unit tests in Java. Today, we’ll focus on using JUnit with a Spring Boot application we generated from This application is pretty basic, but it does allow us to show how one could think about a feature to implement, write tests for the feature, run the tests to see ensure it fails, and then write the code to make the tests pass. A lot of people don’t like to write applications using TDD because it can be a lot slower and feel less iterative.

For those who want to make use of TDD, but prefer their environment to be faster, you can now instantly reload changes to your applications, rerunning tests without restarting environments. For years, JRebel has been the standard for developing your applications without redeploying. Here, at ZeroTurnaround, we think it’s your choice if you want to use Test Driven Development or not. But if you wanted to maximize your performance by using JRebel and practiced TDD then the only option you had was to roll your own test runner and hook JRebel into it manually, until now. Thanks to the “Repeatable tests” mode available since the IntelliJ IDEA 15 EAP, you can use JRebel while you test your code and not have to write tooling code to make it work.

Quick start

We’ve created a simple project to start:, just download it and import into IntelliJ. The feature we want to write is that a simple request to an endpoint returns the text that states JRebel Rocks. This may well be obvious to most of us, but some still need a random endpoint on the interwebz to say it to make it clear. As you can see, this is a Spring Boot application, and it contains a simple JUnit integration test with Rest Assured (a pretty nifty DSL worth checking out). Since we’re practicing TDD, we haven’t implemented any logic yet.

@SpringApplicationConfiguration(classes = TestApplication.class)
public class TestApplicationTests {

    int port;

    public void setUp() throws Exception {
        RestAssured.port = port;

    public void testThatJRebelRocks() throws Exception {
        when().get("/").then().body(equalTo("JRebel rocks!"));

When we run this test, it fails, as expected. You probably noticed that Spring Boot took about 4 seconds to start because this is an integration test, it will start the whole application. This is an empty application so the small start time is expected. If you add some database, security, caching etc you’ll find, your startup time will increase inversely proportional to your patience. Can we reuse the same running instance of the application for testing? Nope, we… oh hang on, YES, we can! Starting from IntelliJ IDEA 15 we can run tests infinitely by selecting Repeat: Until Stopped in the test’s run configuration:

TDD Slow Repeat Until Stopped

Now, when you run your test in this mode you’ll see that each time the test runs through to completion, IDEA will start a new run, however, it will not start a new Spring Boot application.

But, repeatable tests runs without code changes is useless I hear you say. Well, yes, so here’s where JRebel can help! Rerun your tests with the JRebel runner and now you can edit your code and watch your tests turn green. So, let’s add the missing request mapping to our TestApplication with some code that tells the world that JRebel does indeed rock:

public class TestApplication {

    public static void main(String[] args) {, args);

    public String index() throws Exception {
        Thread.sleep(1000); // Simulate some work

        return "JRebel rocks!";

Now, when you press Build -> Make Project your new code will be reloaded and new tests will turn green:

TDD Slow Tests Green

Note that JRebel will automatically re-configure the existing Spring runtime and will add the missing mapping on-the-fly – how cool is that?!

Reload on save

But we don’t want to press Build -> Make Project each time we change our source code, we want to see the result right after we press save in the source file. Is it possible? Of course, it is! I wouldn’t have asked if it wasn’t! ;o)

First of all, go to Preferences and enable the option in Build, Execution, Deployment -> Compiler -> Make project automatically:

TDD Slow Make Project Automatically

By default IDEA will make the project only if it’s not in “running/debugging” state, which is not what we want. But you can override it in the hidden registry ( Ctrl-Alt-Shift-/ on Windows / Cmd-Alt-Shift-/ on Mac):

TDD Slow Registry change

Just find the key and check the checkbox.

Restart your test – now your code will be automatically reloaded when you press save in the source file, so you don’t need to press Build -> Make Project each time you modify something.

This setup is awesome because you can keep using TDD best practices and still harness the code reloading power of JRebel to speed up your sprint and get rid of that pesky forced downtime.

Responses (2)

  1. Avatar  

    Alicia Faning

    October 7, 2015 @ 10:37 am

    Hi sergei, thanks for sharing this piece of information, I am also working on Java based technologies and looking forward to do things as you have shown here.

  2. Avatar  

    Simon Erni

    December 3, 2015 @ 9:01 pm

    I now have the problem that the Integration Tests are running indefintely. Can I somehow pause them after each run, and run again after each source file change? With Karma I can achieve such a feat very easily. I’m using IntelliJ.

RSS feed for comments on this post.

Leave a comment