CarmaBlog

Sorry, this entry is only available in Français.

I use my last article about Continuous Integration as an opportunity to introduce you another XP (eXtreme Programming) practice: Test-driven Development. Actually, CI is often intricately linked with the practice of TDD. To know more about XP, click on the logo below.

Testing is a critical part of good software development. Test-driven development also known as Test-first development (TFD), is a technique, associated with XP and Agile Programming methods, in which unit test cases are incrementally written prior to code implementation. Unit testing and selected aspects of Test-driven development can be used to improve learning and encourage emphasis on quality and correctness. Most users of Test-driven development use automated testing tools to facilitate code review and to encourage frequent and thorough regression testing throughout the development. These tools, such as JUnit, are very popular.

Two years ago, the main subject of my last-year project was TDD. I have decided to share with you the report I wrote. It presents an analysis of the TDD method, but not only in general, it focuses also on using TDD with the Enterprise JavaBeans specification (EJB).

The EJB specification is one of several Java APIs in the Java Platform, Enterprise Edition. EJB is a server-side component architecture that encapsulates the business logic of an application. This technology is relatively new and complex. One of the biggest issues is that testability has not been taken in consideration, at least not until EJB version 3.0.

TDD in a few words

First, we imagine and write a test (a failing test because no code has been written yet). Then, we write the code in order to pass the test (just the code needed, no more!). Finally, we find the best possible design for what we have (code refactoring) and ensure that the test is still passing.

Usually, developers design, code and, at the end, they test. The reversion between the first and last steps is disconcerting but that does not mean this is a bad thing… You can read my report to learn more.

Actually, this article about Continuous Integration, has been posted only in french. Indeed, I think there is so few document about it in french (and so plenty of it in english), that I have decided to write one.

Nevertheless, I have a definition and some very good materials in english for you here : an article from JavaWorld and three good presentations.

Continuous Integration (CI) enables automated builds of your project on a regular interval, ensuring that conflicts are detected earlier in a project’s release life cycle, rather than close to a release. More than just nightly builds, continuous integration can enable a better development culture where team members can make smaller, iterative changes that can more easily support concurrent development processes. As such, continuous integration is a key element of effective collaboration.

The article here.