Hello dear reader. Welcome back to my blog. We talked in the previous blog about Test Driven Deployment. Now it is time to talk about Behavior Driven Deployment. Behavior Driven Deployment is a software development methodology that combines practices from test-driven development and domain-driven design. As we mentioned in the last blog test-driven deployment focuses development on short, cyclical iterations in which (failing) tests are initially created that define the wanted functionality, and only then is actual code written that ensures those previously-failing tests can now pass. Domain-driven design in the other hand, centers on the concept of domain and domain logic. Thus, DDD practices attempt to simplify the terminology in the project scope by focusing and defining everything in the application as real-world objects or concepts that most people are familiar with.
By the combination of TDD and DDD, Behavior Driven Development aims to simplify development trough the use of a common domain-specific language.
As behavior driven development is derived from influenced by TDD, many of the same benefits apply to BDD as well. BDD it reduces regression. When you have a full suite of tests being continually executed, and with new tests always being added, BDD reduces extremely the likelihood of regression bugs popping up as the code is in constant monitoring and testing.
BDD also improves team communication. Since there is a common real-life basis for phrases and terminology when discussing a project, BDD can often improve communication across the entirety of the team.
BDD has also disadvantages like it requires specifications before development and relies on constant outside feedback.
Personally, I like TDD testing better as the code does what you are testing and believe me when I say that the documentation and specifications are bad for a project. There are usually lots of misunderstanding in the specification of a project. It also depends on the project and the company. Thanks for being my reader again.