Coding Chica

With the current java101 project, we have such a small Maven build, that it runs in under 4 seconds. Why should we care about speeding it up?

• Unit tests added in the future may accidentally introduce race conditions (situations when two or more pieces of code are all trying to read/write to the same resource…intermittently causing unwanted behavior that is difficult to reproduce).
  • By having the tests already running in parallel, we may see the related intermittently failures start to appear shortly after that problematic unit test is added. This will make troubleshooting (often involving looking at recent changes) easier and more likely to quickly find the root cause of the issue.
  • The alternative is that we wait for the unit test suite to get large enough that we need to start looking for ways to reduce build time to improve developer productivity, only to encounter hurdles with old tests containing race conditions.
• Why should we as developers sit around waiting on a build to finish any longer than we absolutely have to? Even if it is a small gain, it is still a gain.
• If our code built by a third party server, we may be charged if our total build time exceeds a certain threshold. Why take any more of the server time than we must?

Gathering Current Build Times

Lets run our existing build a few times to make sure we have a handle on how quickly the build runs with the current behavior. I’m using mvn clean install for this test.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  3.709 s

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.417 s

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.368 s

On average, our build is currently taking: (3.709 + 2.417 + 2.368) / 3 = 2.831 seconds at present.

Update pom.xml

It is a very small change to the maven-surefire-plugin:test goal to enable parallel unit test. This can be further customized as needed to control thread counts, etc. For now, let’s keep things simple and add the following to its configuration section:

<parallel>all</parallel>
<runOrder>random</runOrder>

While the runOrder isn’t strictly necessary, I like to include it because it helps me find those race conditions earlier. If every build I run picks a somewhat random ordering, then the build is more likely to hit those race conditions. Then, the output of a failed build will include a seed, which can be used to reproduce that same ordering, if needed for troubleshooting.

[INFO] --- surefire:3.1.2:test (default-test) @ java101 ---
[INFO] Tests will run in random order. To reproduce ordering use flag -Dsurefire.runOrder.random.seed=27345240139000

Gathering Updated

Use the same build command we used in the initial data gathering step, so we can compare them: mvn clean install

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.456 s

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.464 s

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.436 s

With that small update, our build time is now averaging: (2.456 + 2.464 + 2.436) / 3 = 2.452 seconds. That is an improvement of 2.831 – 2.451 = 0.379 seconds…a 0.379 / 2.831 = 13% improvement even in such a small unit test suite!

Granted, the sample size is very small. However, this gives me enough data to tell it is a change worth making for the time savings even in this very small project, let alone the possible race condition troubleshooting benefits in the future.

Commit

Remember, commit small incremental changes. Now is a good time.