About YAGNI & TDD

You're not going to need it, and you should build the features & functionality you need by.


Kalle Tolonen
April 6, 2024


What's TDD about [1]

  1. List test scenarios you want to cover
  2. Make one item on the list into a runnable test
  3. Make code to so that the test (& all previous tests) pass (adding items to the list as you discover them)
  4. Refactor to improve the implementation design

Rinse & repeat

Rules of TDD [1]

  1. Thou shall not write any production code, unless required by a failing unit test.
  2. Thou shall not write more of a unit test, than is required to fail (assertion failure/program crash/compile error).
  3. Thou shall not write more production code, than is sufficient to make the one failing unit test pass.

Bullet points

  1. TDD's tests provide a feedback mechanism: if something is hard to test, it means the code's design needs improvement [1]
  2. You aren't going to need it is a good principle - don't build stuff nobody asked for [2]. Another way to describe this would be Elon Musk's engineering principles #1 (Make the requirements less dumb) and #2 (Best part is no part).
  3. YAGNI failures are outweighted by their massive successes [2], so it's always safe to bet on less-is-more than the other when in doubt

Designing simple stuff

Simple stuff is quite hard to do. Every feature should pass tests, minimize duplication (Don't repeat yourself) & reduce complexity. TTD covers the first part well, so you should live by: DRY & great naming (methods & variables should tell what they're supposed to do). [2]

Source(s)

1

2

Comments

No published comments yet.

Add a comment

Your comment may be published.