>Eclipse Development Process: Technical Practice – Unit Tests

>The Eclipse Development Process does not go into technical practices that can help with the development of the project. It leaves the management and the development practices up to each group. As I stated in the past I plan to look at how Scrum and XP can be used as alternative to the Eclipse Project Development Process. For the next several entries I’ll be looking at the technical practices from XP that I’ve found useful have adopted to the XSL Tools project.

The big one that can give you the most benefit, but is often one of the least used or implemented is Unit Testing. I’m still not sure why unit testing is not more ingrained into people programming than it is. XP has several rules in regards to unit testing, which are neatly described in the following diagram:

While it is described in the diagram with Pair Programming, it isn’t a requirement for unit testing. Unit Testing is something that should be done regardless if you pair or not. The basic practices that should be required are:

  • Every new feature or bug should have one or more tests.
  • No Code is checked in with out a corresponding unit test.
  • Unit Tests must pass before code is checked into the system.
  • ALL Unit Tests must pass when new code is added.
  • Test should be written FIRST before new code.

These basic simple rules actually help keep your builds clean, and make sure that you are not breaking existing code in other parts of the system. They also help enable other practices like Continuous Integration, and Refactoring.

When you are developing code, you are testing it at some point. Why not make this into an automated test that can be run continuously with every time you make changes? Unit tests should not be optional with the complexity of the systems we write. Failing tests means there is something wrong, as the tests are Testing the Code. If you made some code changes, and the tests start failing, then you have a problem somewhere. Maybe the tests are wrong and need to be corrected, but more than likely some assumption you had made is the culprit and the test is probably correct.

Failing tests need to be given the highest priority to be fixed. Unfortunately from what I’m seeing in eclipse projects, they are given the lowest priority. If you do integration builds, how long between green builds do you go? What problems are the tests exposing that you are not addressing? Builds should be green more often than they are red. If they aren’t, then the basics of unit testing probably are not being followed consistently. It means you have problems that are not being addressed.

This entry was posted in agile, eclipse, testing. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s