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

Henrik Bærbak Christensen2 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” Henrik Bærbak Christensen2 2 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 Christensen33

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 Christensen44

The Iteration Skeleton Each TDD iteration follows the Rhythm (6. All tests pass again after refactoring!) Henrik Bærbak Christensen5 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

Henrik Bærbak Christensen7 Missing in 2nd printing of book Find list on

Henrik Bærbak Christensen8

Refactoring Clean up your code!!! –Or you will slow down very soon… Refactoring != Modify code in any way  Henrik Bærbak Christensen9 99

How to write clean code ”Uncle Bob” –Chapter 2 and 3 are recommended! Naming –Intention-revealing names Methods (Functions) –Small! –Do one thing Henrik Bærbak Christensen10

Some more TDD Reject 17 cent coins Henrik Bærbak Christensen11

And who is JaCoCo really? Ant coverage... Note –100% better than 80% –100% does not mean ”perfect”  Henrik Bærbak Christensen12

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! Henrik Bærbak Christensen13 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 Henrik Bærbak Christensen14

Conclusion

Clean code that works The Test-Driven Development process in one short statement is Clean code that works 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 Henrik Bærbak Christensen16Henrik Bærbak Christensen16

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 Henrik Bærbak Christensen17Henrik Bærbak Christensen17

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 Henrik Bærbak Christensen18Henrik Bærbak Christensen18

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... Henrik Bærbak Christensen19Henrik Bærbak Christensen19

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! Henrik Bærbak Christensen20Henrik Bærbak Christensen20

Tool support xUnit will help us to –Write test cases and test suites Using annotations like [Test] and [SetUp] –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 Henrik Bærbak Christensen21Henrik Bærbak Christensen21

Literature Henrik Bærbak Christensen: –Flexible, Reliable Software, CRC Press 2010 Kent Beck: –Test-Driven Development by Example, Addison- Wesley A whole book on money conversion Martin Fowler –Refactoring – Improving the Design of Existing Code, Addison-Wesley 1999 Henrik Bærbak Christensen22Henrik Bærbak Christensen22