BDD Explained (Behaviour Driven Development)

what is behavior-driven development bdd has become a synonym for user-focused functional testing that's not how it started out i was involved at the birth of bdd and it was originally designed for something else entirely so what is bdd and how can it help us build better software faster hi i'm dave farley of continuous delivery thank you for watching my youtube please hit subscribe if you'd like to make sure that you don't miss any future editions in this episode i'd like to explore two problems building the right things and building them right in the early 2000s i worked for a consultancy called thoughtworks i was based in london although thoughtworks was a global company we worked on lots of innovative ideas and we came up with new ways of approaching software development we were employing extreme programming and test driven development at large scale in complicated projects and we worked alongside client developers and so ended up teaching them the skills of test driven development very often we found that as we were teaching these people they were kind of missing the value that we had found during our practice we'd made lots of mistakes in learning test driven development and we saw the developers that we were teaching go through and make the same mistakes they tended to focus too much on unit testing and so would often fall into the trap of thinking that writing the test after we developed the code was the same thing as test driven development which is not test driven development is writing as about writing the tests before we rewrite the code and driving the development through testing they also tended to focus too much on coverage and aimed for getting high levels of coverage in the code as a goal in itself rather than as a side effect of the way in which they were working behavior-driven development was originally conceived as a way of teaching tdd better of trying to get people to the real high value that we perceived in test driven development sooner in their learning process fundamentally the way that we thought of bdd in those days or that was that bdd meant test driven development done right chris matz and dan north did a lot of the the the the initial work on thinking about what bdd would mean and the idea was is to move the focus away from testing and more towards behavior and in particular the specification of the behavior of the code that we were going to create chris and dan focus a lot when they were thinking about this on getting the words right they decided that specification was a better word than test for what it was that we were trying to create scenario was a better word than test case they decided they came up with the model of of set up action and outcome referred to as given when then given the start commission conditions when we carry out this action then we expect this outcome and they use neuro-linguistic programming a way of using the words to put your brain into a certain state so that you thought certain kinds of ideas to help them along this track i remember dan in particular as a big fan of nlp at this time one of the nlp ideas that stuck very profoundly with me and i still use it today in my test driven development and my and my bdd style tests is to start every test case with the word should if we be in the english language if we begin every test case with the word should it puts our brain into a gear that makes it hard not to then specify some behavioral outcome that's desirable at least harder so rather than test this method we should say should be able to pay with a credit card or should be able to add two numbers whatever the requirement of that test case was trying to express there were two other ideas that were profoundly important at least with my take on bdd and those were the ideas of domain-driven design best captured in eric evans fantastic book domain-driven design which described an approach to design that relied on trying to model the problem domain in eric's book he describes one idea in particular that i think is deeply important in this context which is the idea of ubiquitous language in many software development projects we tend to have different languages depending on the state the the stage that we are working in the the product owners and business people will talk about the requirements in one with one set of words the developers will talk about the design of the software with a different set of words and maybe testers and operations people will talk with different sets of words again and the idea of the ubiquitous language was to smooth out the translation mistakes that are likely if we follow that pattern and instead start to establish a language that is common and consistent whenever we are talking about the software the technical outcome of this approach is that we tend to write software that's more closely modeled on ideas in the problem domain because we use the ubiquitous language that we pick is the language of the problem domain this plays very nicely into bdd we can establish this ubiquitous language and use it to to define the requirements that we're going to work on and then we can capture the specifications that we create in our bdd scenarios um to in that same language and that means that anybody can then read and understand the intent of this particular uh feature that we might be working on the other idea that is really important and and influence this is something that is occasionally referred to as acceptance testing or acceptance test driven development acceptance testing was an important idea and when jesus and i wrote a continuous delivery book we talked about acceptance testing there's a chapter specifically about acceptance testing and i want to quote briefly from from from that to just try and position this acceptance tests are a crucial stage in the deployment pipeline once you have an automated acceptance tests in place you are testing the business acceptance criteria and that's important that's what we're trying to get to when we're working with bdd we're trying to focus on these business behaviors and trying to capture in the form of executable specifications these little scenarios that and then we can use that then to drive the development of our systems all of this though is kind of history we can use these ideas though to have an important impact on the way that we develop software by you by creating and growing and establishing a ubiquitous language and using that consistently to capture requirements and then executable specifications in the form of small bdd tests we can ensure that we are focusing on the desirable intent of our software bdd matters because it's so widely applicable it allows us to solve some difficult problems that are traditionally stumbling blocks in software development it helps in two important ways many practitioners though only focus on one so it's important to recognize and think about both of these the first is to establish the ubiquitous language that i've been talking about to build up this this lingua franca for for for the project and the product that's products that we're working on we can then use that to communicate and it steers our thinking it allows us to focus on the essential complexity of the problem in which we're working rather than getting confused by the accidental complexity of the surrounding systems that we must that we must worry about in building working software to do this we can kind of work on creating these executable specifications and these executable specifications are important the acceptance test driven approach to software development allows us to create these higher level executable specifications before we write any code so if i was an amazon user then maybe an amazon developer then maybe i could imagine writing a specification saying users should be able to go to the checkout and and and pay for it pay for a book and i'd want to capture the requirements in that kind of language so the best approach to do these sorts of things is to focus on capturing these scenarios these executable specifications from the perspective of an external user of the system but there's another part to this we also want to separate what the system does from how it does it we want these tests these specifications to say nothing at all about how the system works and only focus on what the system does here's an example this is an example written in the gherkin programming language from cucumber or spec flow and this is imagining that we're going to add some numbers in a calculator and i'm not going to read through all of this but i'd just like to point out that we could do better there's leaks in this example that tell you something about how the system works so it says in the scenario when i had two numbers if i've entered some number into the calculator or some other and i press add well do i really need to say when i press add what if i had a a calculator that was voice controlled and didn't have any buttons what if i had a calculator that was thought controlled and i wanted it to add the numbers when i thought add these numbers then this specification would be right if i said something instead that was more like when i add the numbers now i'm not leaking technical detail of how the system works i'm rather focusing on the behavior that i require of the system and then then the result should be 120 on the screen well why why bother saying on the screen maybe it can inject it into my mind maybe it can speak the answer maybe it can send me the answer via a text message whatever if i can eliminate these technical details it makes my specifications more durable and that's deeply important because that's a mistake that we often see i often see organizations with bdd scenarios that look much more like this one this is going into almost every detail that you can think of when i navigate to the screen i'm going to type this into this field and i'm going to get press this button and then i'm going to type this into this other field this is not the kind of thing that we're looking for and here is a simple real world example that i lifted off after the web it's talking about when i go to the main page and when i i put this value in here um it's not even clear what this is testing so these are not the kind of things that we that we want to achieve we don't want kind of clickety clickety kind of test cases we're trying to express the ideas what is the desirable behavior what is the desirable outcome of this change these ideas are just as applicable to the detailed unit test focused test driven development it's just as correct to want to express the desirable behavior of our system when we're writing a small method as it is when we're creating a whole system so the the modern take on bdd of this being primarily about user focus focused functional testing it's absolutely valuable there it's extremely valuable there and the collaboration with users to build the ubiquitous language and so on is of extreme value but that's not all there is this is equally valuable at the point at which i'm writing a a small unit test aim for behaviorally focused tests across the board focus on the behavior what the system should do rather than the implementation how it should do it always in any test that you write create a mini executable specification even at the unit test level and write all of the tests from the perspective of the x of an external user of of that piece of code it's true that sometimes the external user might not necessarily be the same thing as an end user i'm not talking about at the function at the detailed unit test level writing it from the perspective of somebody typing into a web page what i am saying is think in terms of the business problem that you're trying to solve think in terms of the behavior of this piece of code and maybe the user of that piece of code is another developer but you should be thinking about it from their perspective not from your perspective as the implementer of this piece of code here's a trivial example in this silly example in python here's a test case and it starts with the word should as i described it actually starts with the word test but that's because python's awkward and you can't you need test to start with test if you want the test runner to pick it up but we're going to start with the word should and in this case this test says that we should be able to start an engine and then we break this down into give and when then step so given that we have an engine and we've got a car with an engine when we start the car then we expect the engine to start now all of that says nothing at all about how cars or how the cars or the engine works but these are low-level simple pieces of code from which from this specification i can create and implement a variety of different ways of solving this problem and that's the power of behavioral separation in test cases whether they are small unit test cases or large functional test cases both are enormously valuable in this context you should consciously avoid any knowledge of implementation in the test case in summary then i think that bdd is an important idea i think that it is very very closely interwoven with ideas like acceptance test driven development and the acceptance testing that we described and define in continuous delivery but i think it goes further than that i think that if you adopt the disciplines of be of a behavioral focus in the creation and execution of your tests it can give you a step up in the quality of your tests across the board whether you're talking about these higher level functional tests or the more detailed unit tests that we create through test driven development or bdd if you prefer to call it that thank you very much for watching you

Channel: Continuous Delivery

Views: 31,385

Keywords: bdd, Behaviour Driven Development, behaviour driven testing, tdd vs bdd, tdd, software design, software engineering, software development, Dave Farley, Continuous Delivery, DevOps, test driven development, behavior driven development

Id: zYj70EsD7uI

Length: 16min 28sec (988 seconds)

Published: Wed May 27 2020