Test-Driven Development Eduard Miric ă

The problem

However, with testing... A bit faster A bit cheaper A bit better The solution Testing Test Driven Development

Test-driven development A software development technique where you write automated unit tests before you write your implementation code A technique for ensuring good quality and good design “Clean code that works is the goal of Test Driven Development.” -- Ron Jeffries

How to do it Design: figure out what you want to do Test: write a test to express the design – It should FAIL Implement: write the code – Test again – It should PASS Refactor

TDD cycle New require- ment Write new test Run tests Write new code Run tests Refactor Run tests

TDD Cycle Write Test Code – Guarantees that every functional code is testable – Provides a specification for the functional code – Helps to think about design – Ensure the functional code is tangible Write Functional Code – Fulfill the requirement (test code) – Write the simplest solution that works – Leave Improvements for a later step – The code written is only designed to pass the test no further (and therefore untested code is not created). Refactor – Clean-up the code (test and functional) – Make sure the code expresses intent – Remove code smells – Re-think the design – Delete unnecessary code

Clear up a common misconception... TDD != writing tests first TDD =~ writing test first.. but TDD isn’t about testing... TDD is about DESIGN RED -> GREEN -> REFACTOR

TDD Concepts & Patterns What to Test & in What Order? – Details vs. big picture – Uncertain vs. familiar – High value vs. low-hanging fruit – Happy path vs. error situations Implementation Strategies – Faking it – Triangulation – Obvious Implementation Prime Guidelines for Test-Driving – Do Not Skip Re-factoring – Get to Green Fast – Slow Down After a Mistake

Why TDD? Most of us aren’t disciplined enough to test last. Once we have manually tested the system taking the time to write an automated test seems like a pain. Code that isn’t written with tests in mind tends to be very difficult to test without refactoring it first.

But I don’t have time to do TDD! I don’t have time to fix bugs I don’t have time to constantly step through code to see if it’s all working I don’t have time to figure out what your code is supposed to do I don’t have time to figure out if my changes will break something in your code I don’t have time to rewrite code Think long-term, not short-term!!

The Cost of Unit Testing

The Cost of Not Unit Testing

Benefits Reduce development lead-time significantly Programmers that write tests are more productive Rarely use a debugger Easy to revert on test failure Programmers tests interface first, then code Shorter implementation time High Code coverage Regressions More modular code

Possible reasons to avoid TDD Tests are programmer focused May not be requirement focused Running all tests are slow Sprinting Refactoring Comparing

TDD Summary Never write any code without a failing test Start from the outside, with acceptance tests Drive design inwards using mock objects Tests should be descriptive specifications Red – Green – Refactor YAGNI - You ain't gonna need it