Test Driven Development (TDD) is an approach where test cases are written before functional code to think about how components should work. It follows the principles of Red-Green-Refactor, writing a test (Red), then the functional code to pass the test (Green), then refactoring the code. TDD leads to well-designed, loosely coupled code with full test coverage that is easy to maintain and refactor with confidence in changes. While it may initially take longer, TDD finds bugs earlier and reduces bugs by 45-90%, saving significant time versus fixing issues late in development.

1. Test Driven Development
DOTAN PATRICH

2. What is TDD
Test First Approach
Leads to think about ‘How to use a component’ first and then about ‘How to implement’.
As much about design technique as testing technique.
As much about documentation as testing technique.

3. Principles of TDD
Red
Refactor Green

4. Principles of TDD - RED
RED – Write Test Code
◦ Guarantees that every functional code is testable
◦ Provides a specification for the functional code
◦ Helps think about design
◦ Ensure the functional code is reachable
Red
Refactor Green

5. Principles of TDD - Green
Green– 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)
Red
Refactor Green

6. Principles of TDD - Refactor
Refactor –
◦ Clean-up the code (test and functional)
◦ Make sure the code express intent
◦ Remove code smells
◦ Re-think about design
◦ Delete unnecessary code
Red
Refactor Green

7. How to do it?
◦ Think about the functionality the unit need to support
◦ Think of conceptual method signature for the unit
◦ Write some test to validate the desired behavior
◦ Reads like a story
◦ One test method per concept
◦ Naming convention for test method prefer behavior description rather underlying method name
◦ This will often lead into refactoring
◦ Write some code to implement the tested behavior
◦ Refactor the code and unit test to avoid duplication & simplify dependencies

8. Take me to the code!
TDD for order class:
◦ Visualize the Order unit and behavior
◦ Will result in some class diagram and stub implementation
◦ Just declare methods and dependencies – do not implement them

9. Take me to the code!
TDD for order class:
◦ Visualize the Order unit and behavior
◦ Will result in some class diagram and stub implementation
◦ Just declare methods and dependencies – do not implement them
Write some unit test:
◦ One method per behavior
◦ Notice naming convention is not aligned Java coding style

10. Take me to the code!
TDD for order class:
◦ Visualize the Order unit and behavior
◦ Will result in some class diagram and stub implementation
◦ Just declare methods and dependencies – do not implement them
Write some unit test:
◦ One method per behavior
Refactor:
◦ Mock Inventory – requires refactoring

11. Tools of the trade
Interfaces
Unit Test Framework
◦ JUnit 4/NGUnit
◦ Hamcrest Matchers – recommended for improved readability and expressiveness
Dependency Injection
◦ Spring
◦ Guice
Mocking Framework
◦ Mockito

12. Guidelines for Testable Design
Choose composition over inheritance
Avoid static and the hard coded Singleton
Isolate Dependencies
Inject Dependencies

13. But how much longer will it take?
Studies
◦ Take 15-30% longer
◦ 45-90% fewer bugs
◦ Takes X10 as long to fix a bug in later phases
Study by Microsoft and IBM -
http://research.microsoft.com/en-us/
groups/ese/nagappan_tdd.pdf
“If it doesn’t have to work, I can get it done a lot faster” – Kent Beck

14. Why TDD?
No dead code
Simple design
Have full-coverage test code so maintenance and refactoring are easy
Executable documentation
No (or minimal) debugging
Confidence in change