Examining Test-First

“Test-first “sounds like it’s about testing, but it’s really about collaboration, shared understanding and better design. Test-first originated with eXtreme Programming (XP) with the focus was on writing tests before code. Fortunately, a natural law of software development is that programs written by first considering their behavior are more flexible and robust than programs written by considering their implementation.

Since then, test-first has expanded to be used between product owners and the team by specifying the requirements in the form of acceptance tests. This is called Acceptance TDD (ATDD)

ATDD requires the collaboration of all parties involved. This collaboration on understanding behavior prior to implementation clarifies what is being required while removing the delay between specification of requirements, their implementation and then their final validation. This both helps ensure the right functionality is built while increasing efficiency.

The benefits of ATDD are

  • improved collaboration
  • clear acceptance criteria
  • prepared for automated testing
  • improved developer-tester communication
  • reduced time for feedback
  • agreement on requirements
  • improved code quality

It’s one of the best steps towards building the right thing in the right way.

For more information see:

Benefits of Acceptance Test-Driven Development using Behavior-Driven Development

How to Start with ATDD using BDD

Unexamined Assumption – Developers spend a lot of time fixing bugs.

I’ve been delivering talks at conferences & user groups for over 20 years. One question I ask at most of my talks for developers is “how many of you spend most of your time fixing bugs?” Throughout all of these years, I get about 9 out of 10 telling me they do. But they don’t.

I go through this conversation with them:

  • Consider a time you were notified of a bug.
  • remember the time you spent trying to reproduce it
  • and then figured out how to fix it and did that
  • And then undid it because it broke something else
  • And then found the real cause and fixed it
  • Now, how much time was actually spent fixing the bug?
  • I’d suggest that most of your time was spent finding the bug.

Now this is not just semantics. Consider from when you write a bug (and yes, do you write them even though you say “I found a bug” as if someone else wrote it 😊 ). And let’s say it was found right away (maybe you have automated testing). It likely wouldn’t take very long to fix, because it’d probably be due to the last thing you did. But if you discover it weeks later, even if nothing changed, it might take you hours or days to find and fix it. If things have changed, it’d take longer. And think of the wasted time you would have caused others.

The moral? Spend a little time so that you don’t have to look for bugs.