Behavior Driven Development is a great way to avoid a common situation we find in the process of software development between teams. Very often, the developers and the business professionals are unsatisfied due to the fact that a lot of overwork is done and that many times, time & resources are wasted.<\/p>\n\n\n\n
In general, the common problem we find is a lack of communication between both sides, implying that developers don\u2019t misunderstand what is needed by the business itself and the business professionals misunderstand what the developers are really capable of.<\/p>\n\n\n\n
In this article I would like to get a deeper understanding of what is Behavior Driven Development, its difference with TDD<\/a>, a few tools to use and great benefits you get.<\/p>\n\n\n\n Behavior driven development, or BDD, is another agile software development<\/a> process that encourages collaboration in a software project between developers, QA, project managers and the business team.<\/p>\n\n\n\n It was invented in 2003 by Dan North as a response to test-driven development (TDD). On the \u201cAgile specifications, BDD and Testing eXchange\u201d in November 2009 in London, Dan North gave the following definition of BDD, which I actually really liked:<\/p>\n\n\n\n \u201cBDD is a second-generation, outside\u2013in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.\u201d<\/p>\n\n\n\n It enables the technical team and the business team to reach their end goals. In fact, it helps when it comes to defining the desired business outcomes, to communicating what needs to be built by the developer and to understanding what are the technical challenges they might encounter. <\/p>\n\n\n\n Basically, with BDD you focus on getting a clear understanding of the software behavior you are aiming for, by communicating with stakeholders. So developers keep their focus on why a code should be created instead of putting too much emphasis on technical details.<\/p>\n\n\n\n Now that we know a bit more about BDD, let\u2019s see what are the main differences with TDD.<\/p>\n\n\n\n Many think that BDD and TDD are the same and many are confused about what is what. When we talk about TDD, we talk about a set process. You are basically using automated unit tests<\/a> in order to give the developers a direction on how to design the software. BDD can be seen as a set of best practices for writing great tests.<\/p>\n\n\n\n I would say that the biggest difference is that Behavior Driven Development you write test cases in a natural language that non-programmers are able to read. To express the purpose of a code, the developers combine their native language with the ubiquitous language of DDD (Domain Driven Design).<\/p>\n\n\n\n Instead of coding the functions, you tell the code exactly what you want it to do, by using a style that is closer to our way of writing a sentences. You get a clearer understanding of what the system should do from the perspective of the developer and the customer while TDD only gives the developer an understanding of what the system should do.<\/p>\n\n\n\n That means that BDD enables the developers and the customers to work together on the requirements analysis that is contained within the source code of the system. Therefore BDD becomes quite helpful when it comes to communicating with all the members of a cross-functional product team.<\/p>\n\n\n\n Instead of having tests that are only helpful for engineers, you have a test that helps all. It improves the collaboration between the parties and enables developers to get a clearer scope of the features that are required and the customer get a better idea of what will be delivered, with realistic estimates. <\/p>\n\n\n\n BDD directly influences the design of the software, while TDD is focuses on the testing. So we can say that TDD focuses on the implementation aspect of the system while BDD, as its name says it, focuses on the behavioural aspect of the system. The priority is not about how it will be implemented but more about what will the user be able to do and what he will be able to see.<\/p>\n\n\n\n So which is better? None. They should be used together!<\/p>\n\n\n\n I think it\u2019s obvious that if I write an article about Behavior Driven Development, there are benefits I would like to mention!<\/p>\n\n\n\nWhat is Behavior Driven Development?<\/h2>\n\n\n\n
How is BDD different from TDD?<\/h2>\n\n\n\n
A few benefits you get by doing BDD<\/h2>\n\n\n\n