1 of 8

TDD

Test-Driven Development: it’s magical

2 of 8

Code is radioactive

  • All code has bugs
  • The bugs have a “half-life” and decay happens through testing (or use), followed by debugging
  • Changing code introduces new bugs!

3 of 8

Testing improves code

🐞 Helps find bugs (duh)

⚙️ Forces modularization

📖 Acts as documentation!

​

4 of 8

Writing a test in TDD

  • Debugging
    • Recreate/isolate the faulty state
    • Write a failing assertion (that the state is correct)
    • Use your test to investigate & fix the bug
  • Writing a new feature
    • Write the user story comments, broken down step-by-step
    • Write the corresponding Events followed by assertions
    • Change your code to make the assertions true
    • Behold at your beautiful test-as-documentation!

5 of 8

Event-driven architecture concepts

  • State: the data that everything depends on
    • e.g. the contents of a postgres db
  • Transformation: a pure function of a state (easy to test!)
    • e.g. some models that live in memory
  • Event: something that mutates the state (trickier to test)
    • e.g. a POST request
  • No side-effects*

​

6 of 8

7 of 8

8 of 8

TDD made easy!

  • Any state can be (re)produced
    • Debug dumps give snapshots of state pre-bug along with the events that led to the bug
    • Manufacturing a desired state is also easy
  • Good reflection helps!
  • Fuzz-testing/simulation testing is powerful