Jan 17

BDD vs TDD

Uncategorized No Comments »

tdd2.jpgMy recent post on BDD was a little bit light and requires some deeper thoughts.

BDD versus TDD is part of hot topics that introduce too much pation too often…so I will bring my 2 cents.

The video that I mention is the post raise key points to my mind about BDD vs TDD:

  • They are both Test first approach
  • They are not incompatible and are not adressing the same kind of validation
  • To some degree, BDD tries to validate behaviour and TDD tries to validate sate,
  • They are both about validation,

Finally, I don’t think they should be opposed, and the pasion around this topics seams, to me, due to mis-understanding about the wording. What is sure, is that they can be used to express the validation of some code before writing it.

They are not incompatible: you can validate a controller for example using TDD or BDD. The test won’t be the same, they will introduce/guide different code to the end…but both will validate that the code works as it is suppose to. Some will rightly argue that you will use Mocks if your controller interact with a class that send SMS for example, and you do not want to pay for the SMSs that you are sending during your test. But using Mocks does not meant your are doing BDD: you can use stub and validate the state of the stub instead of the call to the Mocks.

I think most of the discussions are to some extend steril as both approach are usually both valide. Nevertheless, I found this video very interesting on the rational behind TDD (or BDD) and where it goes. I personnaly dislike the idea of 1 class = 1 test class (same for methods). I think that the grain and organization should be different. The validation that makes sense, is to validate a feature that represent added value for the end-users. This is were is the true BDD. To me BDD just extends TDD (as “test first”) by making the relation between code and feature. Decoupling code and feature is the best way to get better tests as they are close to the features. When I say better, I mean easier to maintain, breaking only when one feature breaks.