Over the past few years, I have tried to justify the use of a BDD (Behavioral Driven Development) framework to express my tests, but not once have been able to say BDD has helped me address a problem which writing tests the non BDD way would not have addressed. I do understand the value BDD brings to the table, but in most projects that I have implemented BDD on, we have tried to provide a solution (BDD) to a problem that does not exist.
Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more)
The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the system in a language that fits the domain.
However, time with the business is minimal and most has to be made of the little time we get with them. Having to validate our understanding on what needs to be delivered, the priorities etc take up most time, but asking the business to read our automated tests is something I have found difficult to get buy in on.
In spite of trying to explain the value BDD brings to the table, the business would not consider this as an important task. And finally, the team ends up writing BDD tests, which is an additional abstraction layer which needs to be maintained.
I have tried on many projects to get the business to validate our understanding of what needs to be tested by sending across our BDD tests, but without much success of the real values BDD actually provides. These days, BDD is used just because it is the IN THING and everyone is doing it, so why shouldn't I do it? I have been able to successfully express my tests in a very domain specific language without having to use BDD and also maintaining the key principle of automated testing "Separate Intent from Implementation".
I would use BDD only if my business is co-located and these BDD tests are used by the business to validate that the story is "Done".
Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more)
- Collaboration between Business and Development
- Ubiquitous Domain Language
- Focus on the behavior of the application
The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the system in a language that fits the domain.
However, time with the business is minimal and most has to be made of the little time we get with them. Having to validate our understanding on what needs to be delivered, the priorities etc take up most time, but asking the business to read our automated tests is something I have found difficult to get buy in on.
In spite of trying to explain the value BDD brings to the table, the business would not consider this as an important task. And finally, the team ends up writing BDD tests, which is an additional abstraction layer which needs to be maintained.
I have tried on many projects to get the business to validate our understanding of what needs to be tested by sending across our BDD tests, but without much success of the real values BDD actually provides. These days, BDD is used just because it is the IN THING and everyone is doing it, so why shouldn't I do it? I have been able to successfully express my tests in a very domain specific language without having to use BDD and also maintaining the key principle of automated testing "Separate Intent from Implementation".
I would use BDD only if my business is co-located and these BDD tests are used by the business to validate that the story is "Done".
I agree that BDD has become way to liberally applied due to popularity, although my experience has led me to a different conclusion about when it is most useful. If Dev teams and stakeholders are co-located there should be no physical barriers to prevent you from creating an agile working environment. Why would you want to promote detailed formal documentation over fluid face to face conversation? Trust me, stakeholders will be much more readily available for the later. What I would say is that the principles off BDD should still be invoked here, "give me an example" is a statement I use all the time. On the flip side, if your stakeholders are located off site, you can't do Agile, no arguments, you just can't. Sure you can do screen sharing and conference calls etc, but that all has to be pre-arranged and kills the fluidity. Ultimately you end depending upon more documentation for referencing requirements because you can't get that info immediately from the horse’s mouth. If you have to document requirements, do so using BDD, arrange those conference call, capture those requirements together using specification by example and then implements those test, so that you can show those requirements passing.
ReplyDelete