henrik bærbak christensen1 test driven development “tdd” summary
TRANSCRIPT
Henrik Bærbak Christensen 1
Test Driven Development“TDD”
Summary
Henrik Bærbak Christensen 2
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 Christensen 22
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
Henrik Bærbak Christensen 7
Missing in 2nd printing of book
Find list on www.baerbak.com
Henrik Bærbak Christensen 8
Refactoring
Clean up your code!!!– Or you will slow down very soon…
Refactoring != Modify code in any way
Henrik Bærbak Christensen 9Henrik Bærbak Christensen 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 Christensen 10
Some more TDD
Reject 17 cent coins
Henrik Bærbak Christensen 11
And who is JaCoCo really?
Ant coverage...
Note– 100% better
than 80%
– 100% doesnot mean”perfect”
Henrik Bærbak Christensen 12
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 Christensen 13
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 Christensen 14
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 Christensen 16Henrik Bærbak Christensen 1616
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 Christensen 17Henrik Bærbak Christensen 1717
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 Christensen 18Henrik Bærbak Christensen 1818
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 Christensen 19Henrik Bærbak Christensen 1919
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 Christensen 20Henrik Bærbak Christensen 2020
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
Henrik Bærbak Christensen 21Henrik Bærbak Christensen 2121
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
Henrik Bærbak Christensen 22Henrik Bærbak Christensen 2222