The document describes the author's journey as a software developer and how they learned to release high quality software frequently through adopting test-driven development and other practices. It starts with the author developing software without tests, which led to bugs and maintenance issues. They then learned about unit testing and test-first development, which improved code quality and reduced bugs. Later, they added integration, UI, and behavior-driven tests. Adopting continuous integration and continuous delivery allowed for automated testing and frequent releases. This approach helped catch bugs, improve communication, and deliver working software more efficiently.

1. My journey
as a developer
Or how I learnt to release high quality software frequently
1

2. Fast coding
2

3. Feeling proud!
3

4. No automated tests
4
Lots of manual testing

5. “Software and cathedrals are much the
same – we first build them, then we
pray.”
- Samuel T. Redwine, Jr.
5

6. No confidence in the releases
6

7. A fair few bugs
7

8. No regression suite
8
Maintenance was a nightmare

9. “Don’t use hands to do things that can
be efficiently done by the computer.”
– Tom Duff
9

10. Enter unit testing!
10

11. Code first
11
If manual testing is hard and time
consuming, automate it!

12. Code first is hard
12
Adding tests after the code is
implemented without unit testing in
mind is hard!

13. Test first works better
13
What’s this TDD everyone talks about?

14. No TDD
14

15. So much better
15
• Easier to write unit tests
• A lot less manual testing
• Faster releases
• Easier maintenance

16. There were still a few bugs!
16

17. Tdd: not a silver bullet
17
Unit tests cover a lot of things; but a lot
of bugs happen in interaction between
units.

18. Integration Testing
to the rescue
18

19. Test a few things together
19
If the bug is in interactions, test the units
together

20. Caught a lot of bugs
20
And the automation was a lot tighter

21. There were still UI related bugs!
21

22. Automated UI Testing
22

23. Test it end to end
23
Automated UI tests run through
everything end to end!

24. Demo – UI Automation
24

25. But now business can’t read my test cases
25
No manual testing means
No test cases which means
Hard to verify behavior by the business which
means
Programmers could write the wrong thing

26. Self testing code: no silver bullet
26
• You misunderstand the requirements
• You write the wrong test
• You write the wrong code to pass the wrong
test
• You have a green test suite
• But you’ve implemented the wrong thing

27. “The most important single aspect of
software development is to be clear
about what you are trying to build.”
– Bjarne Stroustrup
27

28. BDD to the rescue
28

29. Behavior Driven Development
29
bridges the communication gap

30. Behavior Driven Development Benefits
30
• Getting verification from BAs
• Automated regression suite defined by BAs
• Always up-to-date software requirements
• YAGNI

31. Demo – BDD
31

32. Acceptance Test Driven Development
32
BDD + UI Automation => AWESOME

33. But this is so slow to run. I’m bored!!
33

34. Enter
Continuous Integration
34

35. Continuous Integration
35
• Integrate the code frequently
• Build the code on each commit
• Run the fast tests on each commit
• Run the slow tests on schedules

36. CI Rules
36
• Fixing red CI is the highest priority
• If you break the build, you do push
ups
• No one pulls from a red build
• No one pushes to a red build

37. “If it hurts, do it more frequently, and
bring the pain forward.”
– Jez Humble
37

38. Enter
Continuous Delivery
38

39. Push to production continuously
39
If everything is tested and verified
properly, then you can push it to
production at any time!

40. Demo – CI & CD
40

41. It feels good
41

42. And the guys who wanted my tests to fail
42

43. THANK YOU
Mehdi Khalili
Senior Consultant @ ThoughtWorks
www.mehdi-khalili.com
@MehdiKhalili