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 ?
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 ?
