TDD in the real world

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 :-)

36f7b3921277b2ed27eb4798c18266e4?s=128

Steinn Eldjárn Sigurðarson

November 02, 2015
Tweet

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!?
  16. None
  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!