test-driven development why do cars have brakes? 

At the end of this workshop... Build production quality software Experience unit testing Appreciate good design principles Gain insights Taking it further 

No content

“One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment – a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.” The Pragmatic Programmer 

“Legacy code is code without tests.” Michael Feathers, 2002 

code inspection only take you so far... 

A software development technique in which automated tests are written iteratively alongside the production code TDD 

A software development technique in which automated tests are written iteratively alongside the production code TDD 

A software development technique in which automated tests are written iteratively alongside the production code TDD 

A software development technique in which automated tests are written iteratively alongside the production code TDD 

“But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer's burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.” The Humble Programmer, Edsger W. Dijkstra 1972 

No excuses Avoid “we’re too busy” Defer “let QA test the software” Deny “we don’t have bugs” Play dumb “we don’t know how” 

Three simple rules You can’t write production code unless it makes a failing unit test pass. Rule 1 

Three simple rules You can’t write any more of unit test that is sufficient to fail, and not compiling is failing. Rule 2 

Three simple rules You can’t write any more production code than is sufficient to pass one failing unit test. Rule 3 

the development lifecycle 

half-adder circuit 

Core entities Wire Inverter OrGate AndGate Probe 

Courage Introduce change Refactor Evolve the design 

Feedback Improves your design Shows how it works Tells you when done 

TDD doesn't drive good design. TDD gives you immediate feedback about what is likely to be bad design. -Kent Beck 

Simplicity Clean code Simple design Evolution 

Communication Documents behavior Reveals intent Tells you when things stop working 

Good unit tests are... Fast Isolated Repeatable Self-validating Timely 

“Brakes allow you to travel faster because you have the power to stop.” So why do cars have brakes? 

suggested reading