mad

Unit tests are uselesss if they are not launched often, automatically and do some noise when crashing !

Hudson, Jenkins or Whatever

Rule N° 1 : You need a system to launch your tests automatically.

Whatever the system you use.  If you have a simple look at what Google tells you about continuous integration you’ll understand the importance of it. Even with “legacy” projects you can use Jenkins. So I won’t elaborate on it here. But be sure this not a gimmicky trend : this is how you do software quality nowadays.

In effect : what’s the point of having unit tests if nobody launches them ?

Our integration server runs on a spare machine in the center of the open space. Easy to administrate.

You Never Know When It Will Break

Rule N° 2 : You need a system to launch your tests often.

Again : what’s the point of having automatic testing if it occurs once in a week ? Or even once in a day ?

We configured our Hudson/Jenkins system to run tests every two minutes if code has been committed.

Excellent !

Rule N°3 : When it crashes it must crash loudly.

Everybody owns the code. Because code is not just for geeks, it’s your product. So even if you’r not a programmer, you must know when you product is broken.

In our system when a single tests fails a sound is loudly emitted on the host machine in the center of the office. This sound is disturbing. Because we work in an airline we use alert cockpit sounds.

When the tests are up again : a big bright “Excellent” rises from the speaker to let everyone know it’s fine now. Sometimes we feel like we want to repair thinks just to hear this sound.

An Example : The Day I Nearly Exploded

One day I was working on an important subject. I needed peace of mind and calm. It’s rare to have it in an openspace.

But it became worst when every 2 minutes our tests failed on the integration host.

I didn’t want to check it immediately, I needed to concentrate. But it was bothering me. So I put my headphones on.

I didn’t hear it. But it was in me : something is broken.

After 5 hours of this, I finally checked the name of the person who broke the tests, then called him. It was repaired in 2 minutes.  And our big “Excellent” rang in the space. What a relief !

TODO

  • First : do you have an integration workflow ?
  • Second : is it automatic ? Really automatic ?
  • Third : does it run loud automatic frequent unit tests ?
If you answered “no” to one of this questions : go find your team  and ask them to install it NOW.
When a new project starts be sure to allocate a few days to setup your automatic integration process.

For the developers out there

What is your attitude towards failing tests ? Do you correct it ? Find the responsible ? Or just wait for someone else to correct ?

Be Sociable, Share!

3 Responses to “Test Culture Episode 5 : “Hudson. We Got A Problem””

  1. [...] the essential nature of unit tests : brake when something is wrong (remember last episode [...]

  2. Why did you have to call the person who broke the build?

  3. The integration machine is not authorized to be accessed from outside. But we work with external contractor. People in this team don’t have access to our Hudson. That’s the fallback of being a pioneer team in the continuous integration in our company : not support, no network, no backup.

Leave a Reply

Seo PackagesWhat is seoseo tips