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 ?

Flight Crew Mobile Software Engineer
Applications should be robust and extremely well designed. Whatever the domain and the medium.

I fight for that with the help of talented people. I want to help you in this mission too.

Fervent supporter of unit testing, constant refactoring, agile approach and good user experience design from scratch. I also believe in the well conceived truly RESTful APIs.

Love to learn through real projects. Invent new ones if necessary.

Also invested in business and culture comparison between France and Korea (my wife’s country).
Currently learning Korean.

저는 프랑스 소프트웨어 엔지니어이며 사업에 관심이 많습니다. 창조성과 팀워크의 개선을 항상 바라고있습니다. 영어를 능숙하게 구사하며 한국어는 배우는 중입니다.

소프트웨어(새로운 Agile 기법이나 단순 폭포수 접근법을 이용한) 개발에 대한 도움이 필요하다면 저에게 알려주세요.

제 부인의 나라인 한국을 사랑합니다. 한국 관련 사업의 기회와 문화를 접하고 싶습니다.

한국이나 프랑스로의 수출을 구상 중이시라면 저에게 알려주세요.
프랑스 문화와 비지니스에 대한 저의 사견을 제공해드릴 수도 있습니다.

* Specialties: iOS front-end, backend API and server logic (mainly in Java)
Unit Testing, Continuous Integration. Agile Approach.
User Experience and Product Improvement (via A/B testing, analytics and user interviews)
Eclipse RCP, JFreeChart, OpenGL, Data Visualizations.
* Interested in : Startup and entrepreneurial adventures, Big Data Science/Mining, Drone development in urban environment, connected cars, augmented reality for tourism and culture, in flight entertainment, high frequency operations and highly available and scalable architectures in general.

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