TDD VS BDD
Last updated
Was this helpful?
Last updated
Was this helpful?
TDD is about writing tests alongside development, in fact, technically they should be written first. The idea is to have a mentality of what it could go wrong before even writing the code, to avoid as many issues as possible. BDD is more about communication. BDD without communication is a really really bad idea, it just adds a layer of complexity to writing tests. With BDD you try to communicate the features and criteria of "done" while planning in a way that's understandable to everyone involved, even if they don't know how to write code. BDD between SDEs and SDETs is also probably not needed.
But it would be great for a QA with an amazing testing capacity to share a test idea with a dev, for example. If that QA person does not know how to write code Or to tell a product owner that also doesn't know how to write code. The idea is still to try to think about testing as early as possible, but, it is all about communicating it and making it available for everyone in the team.
-- Noemi Ferrera
I don't believe in BDD at all. Having worked with 5 other SOlutions Architects who have seen 1 or 2 successful implementations of BDD across the entire globe in our 75 years of automation experience, it makes me very skeptical. The creator of Cucumber, Aslak Hellesoy is amazing and can do BDD correctly. I have not seen anyone else that does that. I think that every Dev should do it. Not 100% TDD all the time. But definitely writing tests, and most of the time writing tests before the software.
I've actually written about this in-depth if you want a deep analysis:
-- Nikolay Advolodkin
