#08 Test Driven Development

Software economics book resources

Sorry for the mess! This version is just a first draft ;-)

Términos a googlear

I.N.V.E.S.T., Test driven development, test first, unit testing, test doubles, mocks, stubs, test pyramid, code coverage …


Programmer test principles

Avoid religion wars. Programmers test should:

  • Minimize programmer waiting.
  • Run reliably.
  • Predict deployability.
  • Respond to behavior changes.
  • Not respond to structure changes.
  • Be cheap to write.
  • Be cheap to read.
  • Be cheap to change.

GeePaw Hill: TDD and the pyramid problem: strategies

  • link
  • pyramid problem: how much code is “in play” during testing. At some point it becomes “a lot”
  • why “pyramid”? big pyramid-shaped piles of dependencies: top is the app, bottom are primitives
  • the more code that´s in play, the more expensive the test for that code
  • TDD isn´t a religious exercise in intellectual purity, we´re in this for the money: for shipping value faster
  • as the cost of the tests rises, their value to me drops. And the relationship isn’t usually linear. At some point, that cost flips TDD’s value proposition entirely: far from making me go faster, TDD makes me go slower.
  • slow runtime, reading & writing & scanning difficulty, debugging pain, combinatoric pain
  • best tactic: break the dependency tree into subtrees, test them separately, and test the higher levels without using the lower ones
  • rearrange code to break dependencies
  • That´s why TDD is first-class citizen in software design



  • Testing in production