Test Driven Development - 2 hour Crash Course with Robert C. Martin [Object Mentor]
Systek, IT Fornebu, 2008-04-08
Notes from the meeting
Tools: IDE (IntelliJ), Junit, Fitness. Platform: MAC.
We were introduced to rules of Bowling: Game of 10 x 2 frames.
Requirement: Write program to register rolls of bowling pins, and compute final score.
We created UML diagram with classes: Game, Roll, Frame, TenthFrame. The diagram is a rough design guide. In our case, the UML diagram showed up to have more classes than required by the implementation. By using test driven development, we created the simplest possible solution, and tests to prove that it works.
Rules of development:
Iterate:
Write the simplest possible unit test method. Compile it. Run it – should fail.
Write the simplest possible code method causing the test to pass.
Advance to the next most simple test, goto step 1.
Agile development: principles
Inner circle: key elements: Unit test – Refactoring
Outer circle: Acceptance test
Software is made soft, i.e. it can be changed: Your loose the fear for changing the code because instant test will prove that it still works or breaks
User story – feature to be implemented in one iteration, decided by manager and development team
User story delivery rate – ca. 45/week (average, 40-49)
User Stories left: Start w/500, reduced w/45 for each week
Iteration cycle: 1 week (best), some use 2 weeks, other 3 weeks – too long
Get addicted to “Push the button” in Unit test and Acceptance test to display green success bar – similar to lab experiment with mouse pushing the button to get happiness stimulus electronically into its brain
Rules
Do not write a single code line before the first test for the code has been written.
DRY – Do Not Repeat yourself, neither in test or production code
Comments – feel shy when writing them, they tend to rotten. Instead, write self explaining code.
Do not separate code segments with comments – instead, make them functions.
Refactor continiously.
A function or method named X should have body size of 1-10 lines.
Functions should have from 0 to 3 arguments (best to worse).
For functions with 4 args, args should be converted to objects (e.g. draw(x0,y0,x1,y1) → draw(Rectangle).
A class should have no more than ca. 10-12 variables.
Instead of f(boolean a), create fTrue() and fFalse().
Never return null, since the caller then should create an if statement and sometimes fails to do this, causing bugs.
Code should be readable – replace score += rolls[i] + rolls[i+1] with score += firstBall(i)
Unit test the formal (public) API of a class.
Key selling points
A system with 45K lines of code had 1/3 test code. Test code is similar to accounting credit and debet – balance of 0 shows it is probably not broken.
The defect rate goes down with a factor of 10 for TDD code.
Production efficiency goes like this: Very high in the beginning, then slower. Management put on more people and productivity immediately goes some up, then decays.
A system under refactoring is stable at all times – all tests pass
QA people write Acceptance tests in Fitness, developers executes these tests.
Ruby:
Dynamic types – the caller does not need to know the type and methods of the called object. TDD enables hard testing of objects with dynamic types, type that the compiler detects in static typed languages (like Java).
Closures – a code block can be passed around as an object and get methods added
Size – 1/5 size of Java code.
AR comments:
The technique seems to stem from Smalltalk, and can be used on static and dynamic languages. There were no getters or setters (getX(), setX(x)), like used to in Java. Instead, the focus was on writing as simple as possible (which is good). There was no focus on public, protected and private scope. The technique makes it efficient to locate and fix errors at any time, and to change structure without changing behaviour. This in turn makes maintenance of production code easy – you can change it, because you have lost the fear of introducing unknown bugs caused by the change. Encap would benefit from using this technique to a much larger degree than what is present today.
