Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Steinn Eldjárn Sigurðarson

November 02, 2015
Tweet

More Decks by Steinn Eldjárn Sigurðarson

Other Decks in Programming

Transcript

  1. QuizUp in the beginning • Few client tests • A

    lot of server tests • Server tests often too large and slow • .. or worse: flaky
  2. QuizUp in the beginning • Several server deployments every single

    day • Client releases were a lot more scary
  3. QuizUp 2.0 • Excellent test coverage of clients • Total

    rewrite — it was hard, but it worked!
  4. Different types of tests • Unit tests? • Integration tests?

    • System tests? • End-to-end tests? • … the evil ice cream!?
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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!)
  10. CI / CD • What’s the purpose of CI? •

    Automate test runs to prevent regressions • Increase confidence for deployment or release
  11. 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