With the advent of Extreme Programming, Agile methodologies and Test-Driven Development (TDD) has come a newfound, almost reverent, respect for testing. Testing used to be an afterthought – so separated from the software development process that it was relegated to a secondary team of “Quality Assurance engineers”. The QA engineers were often thought of as the “B” team, at least by the main (or core) engineering team (who were, naturally, the “A” team). QA were also pariahs for questioning the quality and correctness of the “A” team’s output (how dare they!). Understanding this battle and estimating winners and losers was important when it came to predicting delivery dates in the waterfall methodology. Fast forward a few/many years (depending) and testing is now a “A” team activity – a forethought driving development rather than simply validating it. The trouble is: many developers don’t do tests so well. And writing tests is not the only problem…
In my workshops at Ruby Hack Night, we have been completing a series of exercises to improve the situation within the community – each focussed on developing a different skill in the TDD spectrum.
There are three skills that are critical to TDD:
A. Writing good tests
B. Writing new code or extensions to existing code
C. Refactoring
These three skill map directly to each of the terms in “Red, Green, Refactor”.
Writing good tests requires two things: (1) listening carefully to the customer to capture the correct requirements [we will explore ways to develop listening and analytical skills in upcoming workshops], and (2) accurately translating these findings into valid, complete “code-specifications”. RSpec and MiniTest provide reasonable DSLs for making this about as painless as possible. Of course, as with any new languages comes the need to learn them – and this is something we focussed on developing in our last workshop.
Within the context of TDD, we are constrained to implement new functionality using the simplest, most trivial code possible to pass the tests. This is often something that newly minted developers do better than experienced devs. In our second workshop we explored this and found many of the experienced devs too eager to jump to generalizations rather than focussing on simplicity. Here is some help…
Uncle Bob has written a useful blog post which provides a framework for measuring code simplicity. It is titled The Transformation Priority Premise. In it he attaches a name to the process of extending code (B, above) calling them “transformations”. Transformations are simple operations that change the behaviour of code. He also provides a list of transformations ordered by increasing complexity. Simpler transformations near the top of the list are then preferred over those lower – providing a way to measure the simplicity of proposed transformations.
Finally, refactoring is the process of changing the structure of code without changing it’s behaviour. It is the companion to transformation and is focussed on the single goal of improving code quality. We looked at this process in-depth in the first two workshops.
We are nearing a time when we can bring all of this TDD know-how together into an attempt against a significant TDD exercise. I hope you will join me in the coming months at Ruby Hack Night.
[Click for more articles from our Development series]
[Click for more articles from our Workshop series]
[Click to learn more about Ryatta]
