The document discusses Test Driven Development (TDD), outlining its agenda, principles, advantages, and comparison to the waterfall model. It emphasizes a cycle of adding tests, getting them to fail, writing code to pass the tests, and improving design, highlighting both short-term and long-term benefits of TDD such as enhanced user-friendly API design and reduced debugging time. Additionally, it contrasts TDD with waterfall methodologies, focusing on the incremental and adaptive design process driven by tests.

1. Test Driven Development
Todays Forum Topic:
Test Driven Development
(TDD)

2. Agenda Test Driven Development
Agenda
1. Learning the TDD Process
2. Waterfall vs. TDD Process
3. Short-term advantages
4. Long-term advantages
5. Common critics and answers

3. TDD Formula Test Driven Development
1. add a test
4. improve design
2. get it to fail JUnit JUnit
through refactoring
3. write enough code to pass the test

4. Test Driven Development
User Story
Role: As a user
Feature: I want to be able to create my shopping cart with products
Business Value: So that I can estimate my costs and buy my products

5. Test Driven Development
1. add a test...

6. Test Driven Development
Mac Shortcut: „ CMD + 1“
Windows Shortcut: „ Win + 1“
2. get it to fail...

7. Test Driven Development
3. write code to pass the test...
... in the simplest possible way
JUnit

8. Test Driven Development
4. improve design
too simple in this case, later...

9. TDD Formula Test Driven Development
Start the loop again....
1. add a test
4. improve design
2. get it to fail JUnit JUnit
through refactoring
3. write enough code to pass the test

10. Test Driven Development
1. add a test...
think about the new API before it will be created

11. 2. get the test to fail... Test Driven Development
Generate now the new missing classes and methods

12. Test Driven Development
3. write just enough code to pass the test...
JUnit

13. Test Driven Development
JUnit JUnit
by switching from a red bar to a green one, we
tested our test itself
we fulfilled the test through last implementation

14. Test Driven Development
4. improve design
any change JUnit
• evolve your design
• create only needed abstractions
• be always sure the code is still working

15. Test Driven Development
Start the loop again....
1. add a test
4. improve design
2. get it to fail JUnit JUnit
through refactoring
3. write enough code to pass the test

16. Test Driven Development
1. add a test...
motivate the next new feature by a test!

17. Test Driven Development
2. get it to fail...
Mac Shortcut: „ CMD + 1“
Windows Shortcut: „ Win + 1“

18. Test Driven Development
2. get it to fail...
JUnit

19. Test Driven Development
3. write code to pass the test...
... in the simplest possible way
JUnit

20. Test Driven Development
4. improve design
always supporting your steps
by the test, stay „green“
JUnit

21. Classical waterfall process Test Driven Development
Analysis
A new feature
Customer
Project Manager or a small library
What? Design
Architect
Senior Developer
How? Implementation
Developer
Test
Developer
Tester

22. The process resulting from TDD Test Driven Development
Analysis = Test What?
1. add a test
2. get it to fail JUnit JUnit 4. improve design
Design
How?
3. write code to pass the test
Implementation

23. TDD vs Waterfall Test Driven Development
Waterfall: Analysis Design
GAP
Formal language lack
TDD:
ShoppingCart ....
...shouldHaveAListOfProductsInsideItself
...shouldCalculateTheSubotalOfAllProductsInTheShoppingCart
Behavior Driven Development (last evolvement TDD) is binding the
user stories directly to the tests!

24. TDD vs Waterfall Test Driven Development
Waterfall:
Design
• predict the right design (M.Fowler, Is design dead?)
• think about everything upfront?
• sit down and think where to start, make random drafts
TDD:
• dont think about the design in detail (at class level)
• adapt your design to your needs later, create the abstractions you will only need
• let your design evolve with time
• change the design fast alway assured by the tests

25. TDD vs Waterfall Test Driven Development
Waterfall: Implementation
• fullfill the planned design in anycase
• or develop without any plan
• danger to develop things you will not need at the end
• trying to get classes work somehow together at the end
TDD:
• develop only what needed
• dont really think about the design upfront
• get motivated and driven by the test
• try to close the loop to green as fast as possible
• make changes to former code without any concern that you break it

26. TDD vs Waterfall Test Driven Development
Analysis Design Implementation
Test
Waterfall testing:
• hope to have no bugs, creating ad-hoc and random test cases
• since the code is not test friendly => time consuming and of bad test quality (testing of
huge private methods after they are written)
• boring task, trying to finish it fast
• already lost time with manual testing
• will debug the code you wrote days or weeks ago or even not your code
• might be removed with more project pressure
TDD:Your test is already done!

27. TDD vs Waterfall Test Driven Development
Analysis = Test
Is a test still a test ?
We should consider the test as
specification of our requirements!
ShoppingCart ....
...shouldHaveAListOfProductsInsideItself
...shouldCalculateTheSubotalOfAllProductsInTheShoppingCart
Behavior Driven Development (BDD) by Dan North
Large adoption in the rails community with RSpec

28. Short-term advantages Test Driven Development
Short-term advantages
• by writing the test first we are able to think about the API and create it user friendly
• we did not try to achieve the planned design, which is a hard task
• we never thought about design, just started to develop
• we immediately created an executable specification for our code
• the code is born with two clients: the test using it and the client code => reusable code
• avoid loosing the time by build process, build and deploy only if everything is tested
• compiler is assuring the syntax, tests assuring semantics
• write the test once and develop against it, never check things manually for their correctness

29. Long term advantages Test Driven Development
Long term advantages
• agressive refactoring possible through high test coverage => fast reaction on
change => agility
• we will face more bugs upfront and avoid debugging in the future, which is one of
the most consuming time tasks, if the code was written long time ago
• reduce the debugging by QA, which is much more time intensive as by developer
• continuos integration can only be based on a good test suite, TDD is the perfect base for it

30. Test Driven Development
Long term advantages
• tests will enforce compositions oriented design
• this correlates very well with dependency injection of spring
• stubbing can be easily realized, making the test faster and independent
Main Service
DAO external Tax-Service Validation Service
<<implements>> <<implements>> <<implements>>
Stub
DAOImpl ValidationServiceImlpl
Implementation

31. Pro and Contra, decide yourself.... Test Driven Development
Time Invest into TDD
and
Maintenance of Tests
VS
Long term Short term
• invasive refactoring possible through high test coverage => fast reaction on
• by writing the test first we are able to think about the API and create it user friendly
change => agility
• we did not try to achieve the planned design, which is a hard task
• simpler APIs for other team members the new code was used by the test itself
• we never thought about design, just started to develop
• we will face more bugs upfront and avoid debugging in the future, which is one
• we immediately created an executable specification for our code
of the most consuming time tasks, if the code was written long time ago. Author
• the code is born with two clients: the test using it and the client code => reusable code
himself can solve the bugs much faster since he has still the code in its mind
• avoid loosing the time by build process, build and deploy only if everything is tested
• reduce the debugging by QA, which is much more time intensive as by developer
• compiler is assuring the syntax, tests assuring semantics
• tests will enforce compositions oriented design
• write the test once and develop against it, never check things manually for their
• this correlates very well with dependency injection of spring
correctness
• stubbing can be easily realized, making the test much faster

32. Test Driven Development
„Testing upfront takes to much time“
• of not testable code? of course...
• at the end you have to test your code anyway
• have you counted your time spent on manual testing during development?
„Why to write tests for code I may be not use“
• this is only true for a prototype development or a not modularized code