Hello,
Today, I have discovered that Kent Beck has a blog. For the people who don’t know him, the inventor of the Extreme Programming methodology and JUnit (with Erich Gamma). He’s currently working on a new project called JUnit Max:
The first part of the solution is to get smarter about running tests so the average wait to the first test failure is shorter. Tests don’t fail at random. New tests and tests that have failed recently are more likely to fail than other tests, so Max runs them first. Also, test run-times follow a power law distribution (more about this in later posts), so by running short tests first, Max provides more feedback in those critical first few seconds.
I implemented this first, but I found the Eclipse test runner UI distracting. I was just writing a test, I should see the results right in context. The second feature of this first release of JUnit max is to treat test failures like compiler errors. When you save a file in a project, Max runs all the tests in the project. If a test fails, it appears as a marker:

JUnit Max screenshot
I really appreciate this idea because I think it’s a logical tool for continuous integration.
Continuous integration
If you don’t know what Continuous integration is, I recommend you to read this excellent post. I don’t want to write more on this subject in this post, I just copy here the important part concerning the utility of JUnit Max:
As Tim opens the door to his company’s suite, he views the wide-screen monitor displaying real-time information for his project. The monitor shows him that the last integration build ran successfully a few minutes ago on the CI server. It shows a list of the latest quality metrics, including coding/design standard adherence, code duplication and so on. Tim is one of 15 developers on a Java project creating management software for an online brewery. See Figure 2-1 for a visualization of some of the activities in Tim’s day.
Starting his day, Tim refactors a subsystem that was reported to have too much duplicate code based on the latest reports from the CI server. Before committing his changes to Subversion, he runs a private build, which compiles and runs the unit tests against the newest source code. After running this build on his machine, he commits his changes to Subversion. All the while, the CruiseControl CI server is polling the Subversion repository. A few minutes later, the CI server discovers the changes that Tim committed and runs an integration build. This integration build runs automated inspection tools to verify that all code adheres to the coding standard. Tim receives an e-mail about a coding-standard violation, quickly makes the changes and checks the source code back into Subversion. The CI server runs another build, and it is successful. By reviewing the Web reports generated by the CI server, Tim finds that his recent code refactoring successfully reduced the amount of duplicate code in his subsystem.
So, continuous integration gives you metrics on the latest build of the software. The most common ones are the build successes/failures, the test results, the test coverage and the warnings of Checkstyle/PMD/Findbugs. In order to get good metrics, the developer has to launch a private build before committing his modications.
Using Eclipse as IDE, the developer’s life is easier: there are many incremental builders. When a compiler error is added, the developer is immediately informed with a marker in the editor. If the Checkstyle plugin and the Findbugs one are installed, bad practices are directly detected and, in the same way, a marker appears in the editor. So, the developer can rely on Eclipse at an early stage and when he launches his private build, there’s no compiler and bad-practices errors. But what about the tests? Currently, he has to launch them manually in Eclipse: JUnit Max will improve this step. JUnit Max adds a marker as soon as the developer breaks an unit test. I think that this tool is useful and it will improve the efficiency of a programmer.
I haven’t tested it yet, it seems that Kent Beck tries to get sponsors and, at this time, his plug-in is sold. The price is not high, but I think that we need a free version to test it!
Joel and Kent Beck
I know that there was a kind of “clash” between Joel and Kent Beck. There’s nothing wrong about it and the behavior of Kent Beck in this situation was wise. I didn’t search what Joel said, but I appreciate the last sentence of Kent Beck on this subject:
If I had wanted attention out of this situation, all I would have had to do is turn up the heat: call Joel a few names, write a long, detailed rebuttal, and poke at the fanboys who responded. The problem with this approach is that eventually it all burns down to ashes and no one knows a thing more about software development than they did before.

Comments 2
If you follow the links you embed in this post, you’ll find that Kent Beck is not/was never a member of the GoF.
Posted 14 May 2009 at 2:48 am ¶You’re right. It was a mistake. I have updated the post. Thank you for your comment.
Posted 15 May 2009 at 12:59 am ¶Post a Comment