When people say that pair programming reduces productivity, I answer, ‘That would be true if the most time-consuming part of programming was typing.’ ---- Martin Fowler

I’ve been involved in setting up continuous integration for quite a while. So far so good. However, because the project is composed of several components, things were getting a little ugly. The problem was that it spent far too long to finish a complete build, which made me split it into two separate ones. One for the normal, relatively fast build which only performs unit tests and limited report generating. The other one is daily build which takes much longer to generate a complete Maven project site. I still wasn’t very satisfied with this strategy because the normal build still took me 10 minutes to complete. It did not provide static analysis report either (which I really think should be part of a normal build).

The tools I use are CruiseControl and Maven. I have set up one CruiseControl instance for each of the two builds. The root cause of the slowness is that there are many components. Each time we build, we build every component, from the first to the last. Even if only one of the components have changes, we still build all of them every time. I have thought of having one CruiseControl instance for each component. However, that did not work because I had no way of detecting binary dependency. Say if component A depends on component B, we should rebuild A when A has any change. We should also rebuild A as long as B has any change. If A and B all have their own separate CruiseControl instances, I don’t know how to achieve that effect.

Well, luckily I have spotted this paper today: Enterprise Continuous Integration Using Binary Dependencies. The basic idea is that we will publish the latest build artifacts of all components to a central repository. If component A depends on B, then it will fetch B from the repository instead of building B manually. When we are building A, we check in the repository whether the latest version of B has been modified or not. That way we can detect changes from binary dependencies!

The key for me is that CruiseControl can have multiple modification sets. So I will have one modification set for source code repository and one for binary dependencies. By using Maven, I already have the ability to detect changes of dependenciy versions. Luckily CruiseControl even has a modification set called mavensnapshotdependency (finally there’s some return from using Maven). This way I don’t have to rebuild all components every time. Only build necessary components when only necessarily. What a perfect world!

I find another good description of TDD today.

The main objective of TDD is not testing software (though this is a good side effect), but to aid programmers and customers during development process with unambiguous requirements.

TDD help clarify the requirements before we actually implement them, hence TDD help us design better.

You can find the original presentation here: Test-Driven Development - An Overview for managers and stakeholders

I have always been trying to find better ways to express the benefits of adopting test-driven developement. Recently I have found one great way of expressing it:

Testing before coding is like cheating.

I really like this idea.

Back in child time, sometimes I just hoped that I could have known the answers before all the exams. Unfortunately I never had. I never had that luxary. We can never know the result of an exam until we take it. If we can know the answer beforehand, we will always get perfect score.

Programming is just like taking an exam. We never know what will be the exact behavior of a program before the program is implemented. If we want to cheat in this business, we will have to know exactly what will be the program’s behavior. Is it possible? Test-driven development gives us exactly this luxary. By testing before coding, we effectively get the answer first and finish it later. We know what the result will be, and we adhere to that result to finish the work. Isn’t that great? We cheat honorably.

This is the first time that I can be proud of and feel honorable in cheating. I test before I code.