TDD in the real world

This was a guest lecture I did at Reykjavik University in the fall of 2015. The slides are quite dry, and less polished than I'd like, they were written during crunch time at Takumi :-)

Transcript

1. Software engineering Guest talk: Steinn Eldjárn Sigurðarson
2. Who am I?
3. What is software engineering?
4. Why do we test? 4
5. Why do we test? • Not to prove correctness 5
6. Why do we test? • To facilitate changes
7. Why do we test? • To increase confidence
8. When do we test? 8
9. When do we test? • Small projects?
10. When do we test? • LARGE projects?
11. Experience talking: QuizUp
12. QuizUp in the beginning • Few client tests • A lot of server tests • Server tests often too large and slow • .. or worse: flaky
13. QuizUp in the beginning • Several server deployments every single day • Client releases were a lot more scary
14. QuizUp 2.0 • Excellent test coverage of clients • Total rewrite — it was hard, but it worked!
15. Different types of tests • Unit tests? • Integration tests? • System tests? • End-to-end tests? • … the evil ice cream!?
17. Different types of tests • Usually better to test the smallest possible units • Small tests are fast, rarely break and are run often • Large tests with many “moving parts” are slower and tend to break more often due to external factors: • network issues • race conditions • random / rare factors
18. Different types of tests • What happens if you write large/flaky tests, well..
19. Experience talking Takumi
20. Takumi • 91% test coverage on the server side • 35 seconds to run entire test suite • unit test suite covers 57% and runs in 2 seconds
21. Takumi • Been around for ~6 months • Backend code has seen a couple of large refactors • As launch gets closer, refactoring becomes scarier • Tests give confidence to make sweeping changes
22. TDD ALL THE THINGS?
23. Nope. Not really.
24. To TDD or not to TDD? • Often yields clear, concise and testable code • It took me ~8 years to understand the role of tests • You can go far without ever TDD-ing • When in doubt, alternate between coding and testing • Think of test code as the code which exposes the clarity, or lack thereof, of your real code
25. To TDD or not to TDD? • If you end up with a huge suite of tests asserting minor interactions with a huge mock: no • Think of TDD-ing and RG-refactoring like weightlifting: • They build core strength which comes in handy during everyday life, improves your performance in your activity of choice and reduces the chance of injury. • (if done correctly!)
26. CI / CD • What’s the purpose of CI? • Automate test runs to prevent regressions • Increase confidence for deployment or release
27. CD? • What’s the purpose of CD? • Brilliant for shared development/staging environments • When done for large scale systems, rollout is usually slow and easily abortable • Great for development velocity, challenging for service reliability
28. Example CI pipeline
29. Thank you!