Watch this presentation if you want to know what problems TDD (Test-Driven Development) solves for developers, project managers and the clients in charge of software products. Watch the video here: https://www.youtube.com/watch?v=bxk1i-PC-1Q The code used for the demo: https://github.com/yopeso/CodeWayTDDFearlessRefactor

1. TDD, the way to better software by Ursu Dan
Session 2/6 15:00 - 16:00
#Codeway
Dan Ursu, iOS Developer YOPESO

2. The Problem:
Have you ever told said the following things

3. “After the next release
let’s put aside 3 days for
refactoring”
Manager’s thoughts:
“Again with these
arguments about clean
code?”

4. “This task requires me to
change the architecture
so it takes a long time”
Manager’s thoughts: “ But it’s
a simple button, why does a
simple button cause an
architectural change?”

5. “I fixed one bug and 10
others popped up in
another place”
Manager’s thoughts: “I am
starting to think
you are unprofessional”

6. “I’m not sure how the code
works because the colleague
who wrote it is on a vacation”
Manager’s thoughts: “Really
unprofessional”

7. “I don’t clean this piece
of ugly code because i’m
afraid it will break things”
Manager’s thoughts:
“You sound highly
incompetent”

8. “I’ll finish the task and
clean the code
afterwards”
Manager’s thoughts:
“Yet you always seem
to set aside time for refactoring”

9. You should never ask time for refactoring. You
should refactor every time you see bad code.
You never ask time to write good software, the
same way Cooks don’t ask time to cook good
food.

10. So what is TDD?

11. Test driven development is
a discipline that eliminates
fear of cleaning code.

12. Demo
Eliminate fear? What an interesting and fascinating idea.

13. The 3 laws 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 production
code than is sufficient to pass the one failing unit
test.
3. You are not allowed to write any more of a unit
test than is sufficient to fail;
2 You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.2
3 You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

14. 1. Write a failing unit test
2. Make the test pass by implementing it
3. Refactor
Repeat until software is done
TDD laws lock you into a cycle

15. Credits
TDD is popularized by Uncle Bob (real name Robert C. Martin)

16. TDD in live demo

17. I like those unit tests. Can i get a
pair?

18. So how do you get to TRUST your tests?
Follow the 3 laws of TDD. Follow them always. If every line of
code was written to make a failing unit test pass, you will trust
your tests.

19. Before making up your mind on to TDD

20. 1. What would your life be if all your unit test would pass every
minute or so?

21. 2. Low level documentation. TDD generates a low level
documentation so formal that it executes. It never gets old.

22. 3. Since tests are written first they have a massive impact
on your code. Writing tests first makes your code testable.
And another word for testable is decoupled.
You get a better design simply by writing your tests first.

23. So you get:
1. Reduced debug time
2. Complete and reliable documentation
3. Improved design
How much would you pay now for a suite of unit tests?

24. Eliminate fear of
changing and cleaning
code.

25. Consider this:
Perfectly designed systems with no tests
vs
Bad design but fully covered with tests that
you trust

26. Objections to TDD
Q: My manager doesn’t allow me to use TDD.

27. Objections to TDD
Q: Who tests the tests?

28. Objections to TDD
Q: Why not write tests at last?

29. Objections to TDD
Q: I already have a project which was not developed using
TDD, so i won’t write tests because it’s too late.

30. Objections to TDD
Q: I’m working on an application with a cool UI and nothing
else. You don't want me to write tests for the UI do you?

31. Objections to TDD
Q: Testing individual methods or classes is hard. Why not test
the code through the User Interface.
A: Because by the time you run your UI test, you would have
written so much bad code, that a failing test can only confirm
that human beings make mistakes. Testing individual methods
provides feedback much faster, when its not too late.

32. –Robert C. Martin
“It is irresponsible to ship a single line of code
without executing it in a test ”

33. Conclusions
1. Code rots because we are afraid to clean it.
2. To keep a system clean we need to eliminate the fear
3. The only way to do that is by having a good suite of tests
4. In order to get the tests practice the 3 laws of TDD
5. TDD ties deeply into professionalism

34. More Information
Original TDD presentation
https://cleancoders.com/episode/clean-code-episode-6-p1/show
17:00 - 18:00 Software architecture. Letting go of MVC by Ursu Dan