Henrik Bærbak Christensen1 Test Driven Development “TDD” Summary

Henrik Bærbak Christensen 1

Test Driven Development“TDD”

Summary


Test-Driven Development

– To ensure that our software is reliable all the time• “Clean code that works”

– To ensure fast development progress

– To ensure that we dare restructure our software and its architecture

• “Clean code that works”


Clean code that works

The Values

Keep focus– Make one thing only, at a time!– Often

• Fixing this, requires fixing that, hey this could be smarter, fixing it, ohh – I could move that to a library, hum hum, …

Take small steps– Taking small steps allow you to backtrack easily when

the ground becomes slippery– Often

• I can do it by introducing these two classes, hum hum, no no, I need a third, wait…

Henrik Bærbak Christensen 33Henrik Bærbak Christensen

The Values

Speed– You are what you do! Deliver every 14 days!!!– Often

• After two years, half the system is delivered, but works quite in another way than the user anticipate/wants…

– Speed, not by being sloppy but by making less functionality of superior quality!

Simplicity– Maximize the amount of work not done!– Often

• I can make a wonderful recursive solution parameterized for situations X, Y and Z (that will never ever occur in practice)

Henrik Bærbak Christensen 44Henrik Bærbak Christensen

The Iteration Skeleton

Each TDD iteration follows the Rhythm

(6. All tests pass again after refactoring!)

Henrik Bærbak Christensen 5Henrik Bærbak Christensen 55

The Rhythm: Red-Green-Refactor

The Rhythm

6

Works part

Clean part

Introduce test of delta-feature

Implement delta-feature that does not break any existing code

Improve code quality


Missing in 2nd printing of book

Find list on www.baerbak.com


Refactoring

Clean up your code!!!– Or you will slow down very soon…

Refactoring != Modify code in any way


How to write clean code

”Uncle Bob”– Chapter 2 and 3 are

recommended!

Naming– Intention-revealing names

Methods (Functions)– Small!– Do one thing


Some more TDD

Reject 17 cent coins


And who is JaCoCo really?

Ant coverage...

Note– 100% better

than 80%

– 100% doesnot mean”perfect”


Observations

My ‘old style’ programming– I need to write ”ps.addPayment(5)”– Process

• Introduce private field in class (”private PayStation ps;”)• Declare instance (”ps = new PayStationImpl();”)• Ohh – I have to (”new file / ”public class PayStationImpl....”)• Compile / edit / compile a couple of times• Ahh: ”ps.addPayment(5);”

My ‘new style” programming– I need to write ”ps.addPayment(5)”– I write ”ps.addPayment(5)”

• And let eclipse fill in the details, guided by me!


Keep Focus!

Pitfalls

Beware– Introducing test cases that are not in line with specifications!

• Example: Test-drive coin accumulation with 6 and 17 cent coins • Why?

– Fake-it and Triangulations are partners!• The rhythms is ”fake-triangulate-fake-triangulate...”

• Not ”fake fake fake fake fake fake fake fake triangulate dispair”

– Remember ”Break”• Tired brains make lousy code!

– Remember ”Do Over”• Bad code will haunt you – take the wisdom, leave the code


Conclusion


The Test-Driven Development process in one short statement is


But not in that order.– First – you make it work

• quickly; making small steps; sometimes faking it

– Next – you make it clean• refactoring, remove duplication


Confidence and reliability

TDD promises confidence for us as developers– Green bar gives confidence– Failing test cases tell exactly where to look– We dare refactor and experiment because tests tell

us if our ideas are OK.– We have taken small steps, so getting back is easy

(put it under version control !!!)

Reliability– Code that is tested by good test cases is much better

than code that is not


To stay in control

Test code is an asset that must be maintained!– All unit tests run all the time!

• If you change production code API you update the test cases as well!!! You do not throw them away!!!

– Green bar Friday afternoon means go home, play ball with the kids and have a beer!

Bug report from customer site?– A) Make a test case that demonstrate the failure– B) Correct the defect


Programming process

Principles define language!– I can say what I do when I code !!!

• Can you explain to your mate why you code it like this and not like that? And – is this better than that???

– It is reflected practice instead of divine inspiration and black magic...


Reversing order of implementation

Many program ‘bottom-up’– My client needs class X so I

• write class X• write the client code that uses X

This often gives inferior software because the order is “wrong” – you only find out what X should really have done and how the API should really have been after you have made X. Thus X is either rewritten or we just live with stupid method names, unused parameters, and odd calling sequences...

TDD focus on the client’s usage of X before writing X. This clarifies the requirements better!


Tool support

xUnit will help us to– Write test cases and test suites

• Using annotations like [Test] and [SetUp] / @Test and @Before

– Organize and group test cases• In hierarchical test suites

– does not work with JUnit 4.x any more

– Execute test suites• Hit the ‘run’ button

– Diagnose bugs• Examine the failed test case and correct


Literature

Henrik Bærbak Christensen:– Flexible, Reliable Software, CRC Press 2010

Kent Beck:– Test-Driven Development by Example, Addison-

Wesley 2003.• A whole book on money conversion

Martin Fowler– Refactoring – Improving the Design of Existing Code,

Addison-Wesley 1999


Documents

Henrik Bærbak Christensen1 Test Driven Development “TDD” Summary