1. Test-Driven Development Eduard Miric ă

2. The problem

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

4. 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

5. 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

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

7. 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

8. 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

9. 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

10. 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.

11. 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!!

12. The Cost of Unit Testing

13. The Cost of Not Unit Testing

14. 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

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

16. 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