Test-Driven Development

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

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 commonmisconception... • 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'tgonna need it

Test-Driven Development