"Let the developers consider a conceptual design,” the King said, for about the twentieth time that day._

“No, no!” said the Queen. “Tests first—design afterwards.”

“Stuff and nonsense!” said Alice loudly. “The idea of writing the tests first!”

“Hold your tongue!” said the Queen, turning purple. “How much code have you written recently, anyway?” she sneered.

“I won’t,” said the plucky little Alice. “Tests shouldn’t drive design, design should drive testing. Tests should verify that your code works as it was designed, and that it meets the customer’s requirements, too,” she added, surprised by her own insight. “And when you drive your tests from a conceptual design, you can test smarter instead of harder.”

  • 5
    Writhing tests before coding isn't new. It's a principle part of OOAD. You write high level use cases to understand the requirements, and then your lower level use cases, and from those you write your test cases. That approach is more than a decade and a half old, and it works.
  • 5
    Design API, interfaces, etc first, then write tests while writing logic to verify correct logic of the operations your apis execute. This allows you to write tests before logic is written and forces you to think about the requirements your logic has to fulfill.

    It's harder to do than it's proponents make it out to be
  • 5
    True story
  • 0
    @Alice I was about to mention you in this rant
  • 1
    The problem with writing tests after you finished the implementation is that you risk fitting your tests to your implementation.
    The advantage of writing test beforehand is that you define what your implementation should actually do before you think about how it will achieve it.
    You essentially write black box tests.
    Afterwards you can write glass box tests to achieve good test coverage.
Your Job Suck?
Get a Better Job
Add Comment