Test Driven Development has been around for a while but it has been dismissed by many as a superfluous and tedious way of developing software. I have discovered through experience that it helps me create better quality code while turning the development into an even more enjoyable process. In this talk I explain what makes it so great, tackle some of the criticism and share some tips regarding better unit testing.

1. TDD
UNIT TESTING DONE RIGHT
AND PROGRAMMER HAPPINESS
Nov 2018
Erez Cohen

2. Why would you want to hear about
Test Driven Development?

3. I heard about TDD long ago, but in the past year I really put
it to the Test ;)
I discovered that developing using TDD is more rewarding
and more fun then writing the tests after writing the
production code.
You create better code while enjoying the process…

4. WHY UNIT TEST?

5. ☛ Safer refactoring
☛ Easier to check complex functionality
☛ Faster on feedback
☛ Faster to fix
☛ More stable
☛ Easier to write and run / setup
Compared to E2E / Integration tests, Unit
tests are:

6. Note that unit tests
cannot replace
integration and
E2E tests!
THEY COMPLETE EACH OTHER

7. WHY TDD?

8. What happens when you write the tests
AFTER writing the production code?

9. No Fun
(you already
know it works)

10. Quality
Suffers
(We can only do 1 thing well at a time)

11. Hard to cover
everything

12. → Harder to refactor
→ Code “rots”
→ Slows down everyone
THE RESULT:
Eventually, the tests suit is full of holes…

13. → Are we really green?
(When the suit passes, are we good to deploy?)

14. What happens when you write the test
BEFORE writing the production code?

15. ☛ Better quality: less coupling, less spaghetti.
☛ Better coverage.
☛ At any point: Everything worked a minute ago. Means
less debugging.
☛ Order and focus. Next task apparent.
☛ Documentation of the best kind: usage example. And
Always synced.
😁 Fun: Quick feedback on turning a test green

16. → Safer to refactor
→ code doesn’t “rot”
→ Eventually Faster
THE RESULT:
→ Green means green!
The Three Laws of TDD - Bob Martin (Uncle Bob)
https://www.youtube.com/watch?v=qkblc5WRn-U

17. Objection!

18. TDD is dead, long live testing – David Heinemeier Hansson (DHH)
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
Why Most Unit Testing is Waste by - James Coplien
https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

19. ⇣ Longer dev time
⇣ Tests keep breaking on refactor
⇣ Too much mocking
⇣ Bottom-up architecture
⇣ Used where not applicable
Jim Coplien And Bob Martin Debate TDD
https://www.youtube.com/watch?v=KtHQGs3zFAM
Is TDD Dead? - Martin Fowler, Kent Beck And DHH
https://plus.google.com/events/ci2g23mk0lh9too9bgbp3rbut0k
Why do people object to TDD?

20. When in doubt go back
to the source…

21. In our case it is
Test-Driven Development by Example
(Kent Beck ,2000)

22. How to
Unit Test
CORRECTLY?

23. ☛ Test the API of the MODULE
The “Export”/”Facade”. (not necessarily a class)
☛ Don't test the implementation *
☛ Minimize mocks usage
☛ Tests should be independent of each other
The exceptions: complex data manipulation, calculations…
*

24. What should be the trigger to add a test?
It's not "I need to add a new method"
It's "I need to IMPLEMENT A REQUIREMENT"
TDD, Where Did It All Go Wrong – Ian Cooper
https://www.youtube.com/watch?v=EZ05e7EMOLM

25. AVOID TESTING IMPLEMENTATION DETAILS,
TEST BEHAVIORS

26. Ports and Adapters Architecture
Unit test
on these!

27. TDD No TDD

28. TDD implementation: +15 ~ 30% dev time
Bugs reduced: 40% - 80%
Time for fixing a bug in prod vs dev: up to 15x more
The Outrageous Cost of Skipping TDD & Code Reviews - Eric Elliott
https://medium.com/javascript-scene/the-outrageous-cost-of-skipping-tdd-code-reviews-57887064c412
What do the Researches say?

29. Example:
Assume 1000 hours project, 60% bugs reduced using TDD
Result: WITH TDD => 623 HOURS SAVED!
https://medium.com/javascript-scene/the-outrageous-cost-of-skipping-tdd-code-reviews-57887064c412

30. ☛ Start off simple
☛ Keep unit tests small and fast
☛ Check one thing only in a test
Some more unit tests best practices: :
And more:
Unit Testing Guidelines https://petroware.no/unittesting.html

31. TDD IN PRACTICE

32. RED: See the test fail! (Avoid false positives).
GREEN: Make it pass. Quick and dirty.
REFACTOR (optional):
Make the code clean, remove code smells, apply patterns.

33. Uncle Bob's Three Rules of TDD
1. You are not allowed to write any production code unless it is to
make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is
sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is
sufficient to pass the one failing unit test.
TheThreeRulesOfTdd – Uncle Bob
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

34. Uncle Bob's Three Rules of TDD => REFACTORED
1. Write only enough of a unit test to fail.
2. Write only enough production code to
make the failing unit test pass.
Detailed here:
http://www.javiersaldana.com/tech/2014/11/26/refactoring-the-three-laws-of-tdd.html

35. DEMO

36. Thank you