Nikita Chursin
2 min readDec 23, 2020

--

BDD, TDD, and questions to answer

I wanted to post this on LinkedIn, but turned out it’s 600 chars larger, than Li allows. So let it be here.

Several days ago I spoke about BDD and TDD with a friend and former colleague and his new colleagues. And one of them asked "What about A/B testing? Does it makes sense to spend time on BDD/ATDD’ing stuff, that might be thrown away?".

A couple of weeks ago I saw a thread on Twitter from GeePaw Hill about what are the things that the Red-green-refactor cycle of TDD leaves out. A very interesting thread and it lists three questions that you have to answer for yourself when you do TDD.

The questions are:

  1. Whether any given portion of our code will pay us back for TDD’ing it into existence?
  2. How much advance work we do before writing a test?
  3. When have we achieved enough confidence to proceed?

"All three of those decisions are incredibly nuanced, delicate, subtle judgment calls, and if we don’t make them well, every day all the time, TDD just isn’t going to function" says GeePaw.

We’re doing both TDD and BDD/ATDD in our team. And it feels like these questions are equally relevant for BDD/ATDD. Probably, we should even split the first question in two: one for BDD and one for ATDD (automation part of BDD). So, we end up with 4 questions:

  1. Will any given functionality pay us back for BDD’ing it?
  2. Will any given functionality pay us back for automating its BDD check?
  3. How much advance work we do before writing a test?
  4. When have we achieved enough confidence to proceed?

I think it makes sense to write BDD scenarios for all new functionality, since BDD is more about collaboration and requirements. But all the other questions don’t have such straight answers and we have to rely on each individual engineer’s judgement there. And to paraphrase GeePaw “if we don’t make those decisions well, every day all the time, BDD and ATDD just aren’t going to function“.

Speaking of A/B testing mentioned in the beginning, I think it makes sense to write a scenario, but probably not invest to much into the automation... Though, it probably all depends and should be decided case by case. A good example of the 2nd question dilemma, I suppose.

--

--