An example on running Behat from Jenkins

Time for a very short article. I just want to share a little trick that helped me run my Behat testsuite from a Jenkins build.
Most of the articles that I found on Google did not really cut to the chase. Here it is:

1) Create an “execute shell” build step that executes Behat, and outputs it’s results to a jUnit format:

2) Create a post-build “Publish JUnit test result report” action that reads the build/ directory for the jUnit files.

That’s it! If you want to know more about the formatting features that Behat provides, click here.

Screen Shot 2013-05-10 at 00.47.42

Software Development and the Broken Windows Theory

There is a theory called the “Broken Windows Theory“. This theory states that if there is a disorder in a neighbourhood for a substantial period of time, the mess will only get worse. The authors give the example of a broken window in an abandoned building. If it isn’t replaced within some time, the chances are that vandals will break another window. And another. Gradually making the mess worse, and therefore making the issue bigger.

How the broken windows theory relates to software development

This theory applies to quality in software development as well. Over time the quality of our software may decrease for a variety of reasons. For instance, when under the pressure of a deadline we tend to do concessions to the quality of our software. Or when some tests fail, and no-one acts, it doesn’t motivate to write good tests and more tests will fail over time. Effectively making the testsuite useless. This disorder is also known as technical debt.

How it works

The mechanic about this effect is that you unconsciously and gradually lower the norm of quality of your software. This is of course not what you want for your customer. But also for your team.
Not responding to the “broken windows” in your project will effectively change the mindset about quality, and it leads to passive/reactive behaviour. Do you know that feeling that you’re constantly running into problems with existing code? Then you might have had some broken windows for too long!

Fix the windows!

The broken windows theory in full effect
©2012 iStockphoto

The solution that the broken windows theory describes is to actively monitor and report any disorder like a broken window, litter, holes in the road, or graffiti. In software development their equals would be poor code, bugs, failing tests, or bad design implementations.

The key to success is to maintain a zero tolerance policy on technical debt. And to clean up the list of disorders within a timely fashion.
Of course, you and your team have to decide on what you consider technical debt within the project. This will usually be affected by customer expectations and/or budget. But make sure you all agree on what the quality standard is. Otherwise maintaining a zero tolerance policy will be ineffective, and may cause frustration.

It’s in your hands

Implementing this strategy is something you can start doing today. If you start pointing out and act to the so-called technical debt, you will soon start a movement within your team. You will create awareness and team members will follow your example. Social control on the subject will grow, which encourages to stick to the set quality standards.

Ultimately leading to a better product, happy teams, and happy customers!