I will get back here. Notes: 1:28 Separate spec from impl. What, not how. 3:44 Why BDD doesn't always improve our work quality? Reasons: 3:58 1. Confusing UI interactions with behavior. 7:05 2. Attempting programming BY REMOTE CONTROL 8:39 3. LONG RUNNING SCENARIOS. 10:34 NO RE-USE of steps: 10:45 Time and effort waist. 10:50 Thinking wrong. 13:13 4. Scenario OVERLOAD.
Great Video again Dave! I would love to work with you at some point in my life or maybe just have a chat with you. You are a great teacher and probably even a better developer.
"I don't think you can do a really great job in software development unless you understand the problem you are trying to solve." Totally agree, and it's why I only develop software in the field I am working in, for use by myself or by others working in the same field (science).
Excellent view on BDD. I have always nearly hated BDD due to the readability of the test cases where I've seen it used. Now I see the problem is not BDD itself, but rather the anti-pattern where testing is outsourced from development teams to QA team. Then test cases are written to describe the implemented application logic instead of wanted behavior. It is very unfortunate I have learnt this the hard way while working in a company where developers are still struggling with these basic concepts. I think most of these mentioned mistakes are part of the our process and culture. Years back there was a project where writing unit tests was forbidden as management saw writing them was slowing down the development and the project was not seen as very important. Well, it has been maintained and enhanced for ten years and counting. The code is ofc total garbage so I don't think the decision was correct:)
No, the problem is the tool. BDD was not created to inject it into a something based on Gherkin language, which is btw a mental trick and a nightmare for testers. The new 3rd gen low-code/no-code automation platforms solve this problem because they mimic the end user and suites are easy to maintain. You don't create millions of microtests but reuse the artifacts of the time. The only problem they have is that they are not accepted by devs because there is no code, but I see it as a temporary act of neoludism 😄
That is like people do with Agile and Scrum, they conflate the tooling with the approach and mindset. When I was a junior, I sure did that too. Specs and Gherkin are cool tools but seeing the value of it in the bigger picture is hard. Putting it into practice can also be a challenge.
I wonder if this is a "senior" vs "junior" thing, or more about how we learn. In our industry we talk all the time about tech and tools, and almost never about designs, design thinking and principles which I think are much more important, much more valuable and maybe easier to learn if only we taught things that way. Dunno if I am right, but part of what I am trying to do is to describe these things in ways that explain how things work rather than define some recipe-like series of steps.
@@ContinuousDelivery Thank you for responding. I have been thinking a lot about this since I woke up and started to appreciate my choice of profession. It is definitely not just juniors, but I think that they are more into programming for the sake of writing code and using the frameworks that they like. The real issue is cultural. In our field we are expected to be technical, and the language we use when communicating with our peers is technical - since that is our plane of existence. It might also have to do with genders. Boys being more into details. Like you do, I wish that "we" could step out of our bubbles, learning how to communicate with others. Leaving the technical stuff aside, focusing on the behavior of our software. Not starting the discussion with which table to store data in. I mean that we should not go directly to implementation without everybody understanding what is to be achieved. I really appreciate your work. Thank you.
Hi Dave. I really need to see realistic(-ish) examples of what you call Unit Tests in comparison to BDD tests you prefer to run in production (which you explain at 14:28). I understand you don't prefer using Gherkin for the unit tests. But I am mostly interested how will those Unit Tests compare to your (in production) BDD tests, especially in hexagonal architectures where SUT is usually the whole application plus domain layers (the core). I love your videos and so far I have watched quite a lot of them and it may be time to start reading the book 🙂
I have training courses on both of these things TDD (with unit tests) and BDD (with Acceptance Tests), there's also a playlist on the channel on testing.
@@ContinuousDeliveryThanks Dave. I have also found some very useful video about testing hexagonal architecture (the most important test types are discussed there at least): ruclips.net/video/LtbHAFsEu5g/видео.html
Great video as always-at the risk of angering the populace, I would like to learn more about these ‘bear traps’. The theory, combined with good intent and reasonable intentions, often get misunderstood when applied practically. Having some idea of when you’re about to go ‘off the rails’ would be very helpful.
I agree you should be wary of over testing with BDD, in a similar way to integrated tests. However, towards the end it is implied you might only apply it at the highest or most outer layer. I often go further and apply BDD from the very start of coding, right through to acceptance, with varying success. An example might be: Write BDD tests during the story writing phase Apply tests directly to the lowest layer in code. Write a single test case, in code, per scenario using TDD practises to identify a solution. (I do not use fancy tools, I just copy a test into a test class and comment it out.) Write unit/contract tests as code emerges. Modify the implementation of the test and apply "outer" layers until a complete “end-to-end” test for the local codebase exists. If the solution includes both UI and API, apply these same tests to both. Quite possibly in the same way, copy, paste, comment out, end-to-end. Apply the tests to a deployment level, as described in the vid. I will sometimes pick specific tests for smoke testing, then the rest for acceptance testing. (At this stage I might use fancy tools :P)
This is so helpful. We're doing several of these. One we are really do a lot is "programming by remote control." Do you have an example of a BDD using programming by remote control and the BDD after its fixed? You're video showed several other before and after BDD examples. This would be really helpful for our training. Thanks for the great video, Dave.
I don't think I have any real world examples that I can share. Basically the check is is the test describing what the users want, or what someone in your org wants to develop. Does it focus on the problem being solved, or the solution? This isn't a great example, but... Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then the result should be 120 on the screen vs Given I want to add 50 and 70 When I add the numbers Then the result is 120
Excellent video. I've adopted BDD in 2007 or 2008, if memory serves me right, and have landed on the same conclusions. Pretty everybody I've coached on the practice swears by it as well.
We don"classical" requirements engineering (among other things). Some of the bad practices you mentioned regarding BDD also happen in our work. Sometimes we get a requirement/ specification right, sometimes we dob"programming by remote control". We had various contractors over the years that did the programming. Somehow our organization was not able to contractually getunit tests. With high certainty they didn't do unit tests in the end (the first contractor didnt because it was no contractual obligation, the rest because of the rising amount of work to close the test gaps and piriority was on new features than on making things right). Dunno organizations don't semm to be able to learn from past mistakes. Our high level testing is based on our specifications. At one point we were considering to try BDD.
You can use it tactically like this. It is not as good as having a proper automated test strategy based on a combination of acceptance testing and unit testing, but BDD style acceptance tests are much easier to retro-fit to a system that wasn't written with testing in mind.
Excellent description & argument. Also, major inside joke points for using the infamous Oracle security hole "scott/tiger" demo account! I guess kids today just didn't get that ;)
Sticking with the example you gave about adding your book to the shopping cart and asserting that it is there. Where is the step that adds the book(s) to the list of available books to choose? Should those be added to it or is there just a set of books that are known to be in there? Would this test break when the business says we want to sort same titled books a certain way so the OG author gets seen (first|last); or what if it was like ebay and distance mattered... These other details business frequently talks about but then I get into that fine line of having too much details or not enough details in my test... and if it wasn't enough and I add it then I have to go and add this information to all my other tests that I've just gone and broke.... still I wish that my current client used BDD instead of nothing. I miss getting to write acceptance tests.
Very good video overall, if for nothing else than to give some food for thought, like many of your videos. Often enough I find the decision on how to approach development isn't as important as the shared understanding of why that decision has been made, and what other options have been considered and the reasons they were rejected. edit: I find a comparison between BDD and Hungarian Notation somewhat interesting, as the idea of both, as far as I can tell, is to represent intent and not specifics, and both are used incorrectly (granted, much of the latter is better described using type systems)
Can you do a video on the language that allows for test specification in "plain English"? I have never seen it before and it looks like magic to me. The idea of de-coupling *what* the code should do from *how* it should do it is really good, but I don't see how these "wordy" tests help. Surely specify what these English words mean (which functions in code they should call), so that you can actually execute the test on a machine, and then that specification of the words will be coupled to the code instead of the entire test. You could just as easily write a normal function that specifies the behavior and call that instead. The test would be just as readable and decoupled, but now you have the added benefit of being able to call that function in your code. You mentioned in the video that these tests don't mean BDD and don't guarantee good tests with good decoupling, so I guess it is just another tool that can be used well or poorly.
I have a few videos that touch on aspects of that already. I am working on a training course that will go into a lot more detail later in the year. Try some of these: "DDD with BDD" ruclips.net/video/Ju50D11EIoE/видео.html "Real World BDD": ruclips.net/video/9P5WG8CkPrQ/видео.html "Better Exec Specs": ruclips.net/video/5CXSEINRojM/видео.html "How to Write Acceptance Tests": ruclips.net/video/JDD5EEJgpHU/видео.html
If BDD does should no focus on testing every input entry, will it not open a security issue where incorrect input or malicious input could compromise the system? How can BDD help us in preventing security issues? Or am I asking the wrong question?
No, you cover that with other forms of testing. Yes you are asking the wrong question because you are limiting the answer to only BDD. If you reframe the question as something more like "how do we prevent security issues?" there are lots more, and better, answers. I am thinking of doing another video on this topic, but I do have this one: ruclips.net/video/NdvMUcWNlFw/видео.html When my team built a financial exchange, we did all sorts of security testing, only a small fraction of it was through BDD style acceptance tests.
There are some really good arguments for using BDD. Thanks, I am taking notes :) Though I might write “Given I login as a Finance Officer” as “Given I am a Finance Officer”. I see the requirement as: You expect a change in behaviour based on who you identify as. The fact that you need to prove who you are is not relevant to this test.
Thank you for great material. I've gathered in my public repository all intresting stuff about BDD (links to books, articles, talks). Your movie and John Ferguson talk is another material fom the collection.
My real answer is "it depends", mostly not the same, but sometimes it is. There are usually more specs than stories. The stories tend to be general "pay by credit card" and the specs tend to be more generic "pay £10 with a personal Mastercard" and "pay £10 with a business Mastercard", sometimes this is called "Specification by Example". There's a grey area, you may decide to split these out into separate stories to organise the work, "Pay by personal credit card" and "Pay by business credit card" for example. So they are certainly closely related.
@@ContinuousDelivery It's confusing, because my mind is used to thinking of DSL (digital subscriber line) as a commonly used acronym for data communication technology.
Dave just said explicitly at the end of the video that BDD is not to be applied to all levels of testing, but mostly at the E2E level, executing the specification against the fully deployed system. There are always exceptions, of course, like if you have some core library that contains a lot of important business logic, you could write executable specification for it in the form of unit tests, but then they would not be called unit tests anymore, I suppose.
BDD belongs at the top (or near top) of the test triangle. If you implement BDD for a level lower than the top, you are looking at a very large maintenance overhead. Use a good unit test framework for unit and integration tests. Use a good unit test framework for the 'corner case' or 'every case' testing. Use BDD for the documentation, support reference, and UAT part of the project. BDD intention (or at least one of the intensions) is to allow the team to decouple behavior from implementation.
I think that this depends on what you mean by "BDD", there are, at least, two different interpretations. I think that today, most people think of BDD as focused on, what I'd call, acceptance testing, high-level functional tests that act as executable specifications for the behaviour of a system. That's the kind of BDD that this video is talking about. But that wasn't what was meant when BDD was invented. It started out attempting to describe a better way to teach TDD. I talk about that in this video: ruclips.net/video/Bq_oz7nCNUA/видео.html I think that this second version is more generally applicable, and sadly, often overlooked. It certainly deeply informs my approach to TDD. It doesn't require the complexity, or tools, that the functional testing stuff does, which I guess is why the idea didn't gain as much ground, people love tools! Ultimately its more important though. It says focus your tests, even your unit tests, on only the desirable behaviour of your code, not its implementation. Even at the level of a simple unit test, write it as a tiny specification of what you want the code to do, not how it does it. So in this form, BDD is nearly the whole testing triangle.
@@ContinuousDelivery "Even at the level of a simple unit test, write it as a tiny specification of what you want the code to do, not how it does it. So in this form, BDD is nearly the whole testing triangle." I agree. The issue I have encountered with that approach is buy in. From experience, BDD buy-in at the 'higher' level of the test triangle has been more palatable to teams that have not used BDD. We have to pick our battles. Per the original comment, TDD at all levels of testing is something to aim for. And thanks for your reply.
The greatest benefit of BDD is twofold -- to extract the business value from across multiple disciplines, while also forming an ubiquitous language that enables efficient ongoing communications. That can be done very well (even online) with the 4-color Post-It note "discovery" sessions. Then the developers can "formulate" the BDD scenarios from that, which will apply nicely to acceptance testing. I also use BDD-style tests (in C++ using the doctest framework) even when designing and implementing library code. Generally, we don't want developers (including me) to create the business logic in a vacuum, because we might make the wrong thing, or add low-value features. But if I'm just writing some tool or module, like I/O, adapters, ADTs, data transformations, algorithms, etc., then it is just to create a self-contained module to support some greater business value(s). It's an implementation detail from the business POV, but it's still something that I want to clearly exercise and demonstrate with concise tests (executable specs), so I know it works in the present, everyone else can see how it works, and any breaking changes in the future will be not only detected, but pinpointed immediately, with an error message that presents the full context.
I don't think that you need a "framework" my preference is to create your own "Internal DSL" hosted in the language that you are using to develop the system. There is a CPP version of Cucumber, I have never used it but take a look here: github.com/cucumber/cucumber-cpp
@@ContinuousDelivery writing anything that is not directly related to the business problem introduces accidental complexity. And commercial companies neither have time nor money to pay for something that is not directly related to the domain. Thanks for the link
Low/No-code automation frameworks will replace BDD in less than 10 years for acceptance testing. And just for one reason: the cost of change is almost zero, you don't need anything else. It is much easier to keep a coherent regression suite and to do analytics. Why do you want to code a test beyond the integration test? I'll never understand that to be honest ... BDD ends always as an infinite number of microtests, which nobody can maintain and absolutely useless.
I can see the usefulness of BDD in defining executable specifications especially for web and graphical user interfaces, but what about APIs, backend applications, and microservices development where most test cases are likely one or more steps away from actual users of the system? Oftentimes the specifications end up writing implementation details instead of a broader behavior-focused definition which makes sense because we don't want ambiguity when testing these backend interfaces.
It doesn't really change the value or the approach. The goal is to express the need not the implementation. This is good for any SW. If your SW is providing "end-user" level services you can use exactly the same specification, but translate "placeOrder" or whatever else the biz concept is into a call to an interface. If your SW is rather more divorced from end-user interactions, then you treat the programmers of services that use your service as the "users". This is more difficult to do well, because if you are used to the bad habits of specifying the solution in your requirements and tests, it is even easier for you to fall back into those bad habits. So need to work harder to keep your specs clean of "solution", but it still works extremely well. I did this with a team that was writing low-level firmware for a scientific device and it worked very well indeed.
@@ContinuousDelivery It is particularly challenging indeed. And it gets worse. In backlog grooming/refinement sessions, we tend to break down/flesh out big item user stories into smaller ones so imagine the constant reminder we get not to fall into that trap, which is silly knowing how programmers think. Thank you for the reply, Dave.
"login" is about authentication, not authorisation. Authorization happens only after the user was authenticated. Otherwise, as presented, BDD sounds like computer science serving the real need of real people, unlike, say, cryptocurrency..
The test was testing wether the user could access something after they had logged in. Authorisation is the real test. But I am nerding out here, I may well have misspoke :)
A common mistake. The name does implies psychology, also the authors of BDD have said they didn't know that BDD was a mental disorder at the time. It was a confusing time googling for stuff in the early days of BDD.
I will get back here. Notes:
1:28 Separate spec from impl. What, not how.
3:44 Why BDD doesn't always improve our work quality? Reasons:
3:58 1. Confusing UI interactions with behavior.
7:05 2. Attempting programming BY REMOTE CONTROL
8:39 3. LONG RUNNING SCENARIOS. 10:34 NO RE-USE of steps: 10:45 Time and effort waist. 10:50 Thinking wrong.
13:13 4. Scenario OVERLOAD.
Great Video again Dave! I would love to work with you at some point in my life or maybe just have a chat with you. You are a great teacher and probably even a better developer.
Thanks 😎
The domain specific language looks like the way of creation software without coding. So certainty your effort is a really revolutional.
"I don't think you can do a really great job in software development unless you understand the problem you are trying to solve." Totally agree, and it's why I only develop software in the field I am working in, for use by myself or by others working in the same field (science).
Excellent view on BDD. I have always nearly hated BDD due to the readability of the test cases where I've seen it used. Now I see the problem is not BDD itself, but rather the anti-pattern where testing is outsourced from development teams to QA team. Then test cases are written to describe the implemented application logic instead of wanted behavior. It is very unfortunate I have learnt this the hard way while working in a company where developers are still struggling with these basic concepts. I think most of these mentioned mistakes are part of the our process and culture.
Years back there was a project where writing unit tests was forbidden as management saw writing them was slowing down the development and the project was not seen as very important. Well, it has been maintained and enhanced for ten years and counting. The code is ofc total garbage so I don't think the decision was correct:)
No, the problem is the tool. BDD was not created to inject it into a something based on Gherkin language, which is btw a mental trick and a nightmare for testers.
The new 3rd gen low-code/no-code automation platforms solve this problem because they mimic the end user and suites are easy to maintain.
You don't create millions of microtests but reuse the artifacts of the time. The only problem they have is that they are not accepted by devs because there is no code, but I see it as a temporary act of neoludism 😄
That is like people do with Agile and Scrum, they conflate the tooling with the approach and mindset. When I was a junior, I sure did that too. Specs and Gherkin are cool tools but seeing the value of it in the bigger picture is hard. Putting it into practice can also be a challenge.
I wonder if this is a "senior" vs "junior" thing, or more about how we learn. In our industry we talk all the time about tech and tools, and almost never about designs, design thinking and principles which I think are much more important, much more valuable and maybe easier to learn if only we taught things that way. Dunno if I am right, but part of what I am trying to do is to describe these things in ways that explain how things work rather than define some recipe-like series of steps.
@@ContinuousDelivery Thank you for responding. I have been thinking a lot about this since I woke up and started to appreciate my choice of profession.
It is definitely not just juniors, but I think that they are more into programming for the sake of writing code and using the frameworks that they like.
The real issue is cultural. In our field we are expected to be technical, and the language we use when communicating with our peers is technical - since that is our plane of existence. It might also have to do with genders. Boys being more into details.
Like you do, I wish that "we" could step out of our bubbles, learning how to communicate with others. Leaving the technical stuff aside, focusing on the behavior of our software. Not starting the discussion with which table to store data in. I mean that we should not go directly to implementation without everybody understanding what is to be achieved.
I really appreciate your work. Thank you.
Hi Dave. I really need to see realistic(-ish) examples of what you call Unit Tests in comparison to BDD tests you prefer to run in production (which you explain at 14:28). I understand you don't prefer using Gherkin for the unit tests. But I am mostly interested how will those Unit Tests compare to your (in production) BDD tests, especially in hexagonal architectures where SUT is usually the whole application plus domain layers (the core). I love your videos and so far I have watched quite a lot of them and it may be time to start reading the book 🙂
I have training courses on both of these things TDD (with unit tests) and BDD (with Acceptance Tests), there's also a playlist on the channel on testing.
@@ContinuousDeliveryThanks Dave. I have also found some very useful video about testing hexagonal architecture (the most important test types are discussed there at least):
ruclips.net/video/LtbHAFsEu5g/видео.html
Great video as always-at the risk of angering the populace, I would like to learn more about these ‘bear traps’. The theory, combined with good intent and reasonable intentions, often get misunderstood when applied practically. Having some idea of when you’re about to go ‘off the rails’ would be very helpful.
I agree you should be wary of over testing with BDD, in a similar way to integrated tests.
However, towards the end it is implied you might only apply it at the highest or most outer layer. I often go further and apply BDD from the very start of coding, right through to acceptance, with varying success.
An example might be:
Write BDD tests during the story writing phase
Apply tests directly to the lowest layer in code. Write a single test case, in code, per scenario using TDD practises to identify a solution. (I do not use fancy tools, I just copy a test into a test class and comment it out.)
Write unit/contract tests as code emerges.
Modify the implementation of the test and apply "outer" layers until a complete “end-to-end” test for the local codebase exists.
If the solution includes both UI and API, apply these same tests to both. Quite possibly in the same way, copy, paste, comment out, end-to-end.
Apply the tests to a deployment level, as described in the vid. I will sometimes pick specific tests for smoke testing, then the rest for acceptance testing. (At this stage I might use fancy tools :P)
This is so helpful. We're doing several of these. One we are really do a lot is "programming by remote control." Do you have an example of a BDD using programming by remote control and the BDD after its fixed? You're video showed several other before and after BDD examples. This would be really helpful for our training. Thanks for the great video, Dave.
I don't think I have any real world examples that I can share. Basically the check is is the test describing what the users want, or what someone in your org wants to develop. Does it focus on the problem being solved, or the solution?
This isn't a great example, but...
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen
vs
Given I want to add 50 and 70
When I add the numbers
Then the result is 120
@@ContinuousDelivery Thank you. This description and example helps. Your videos are very informative.
Excellent video. I've adopted BDD in 2007 or 2008, if memory serves me right, and have landed on the same conclusions. Pretty everybody I've coached on the practice swears by it as well.
We don"classical" requirements engineering (among other things). Some of the bad practices you mentioned regarding BDD also happen in our work. Sometimes we get a requirement/ specification right, sometimes we dob"programming by remote control". We had various contractors over the years that did the programming. Somehow our organization was not able to contractually getunit tests. With high certainty they didn't do unit tests in the end (the first contractor didnt because it was no contractual obligation, the rest because of the rising amount of work to close the test gaps and piriority was on new features than on making things right). Dunno organizations don't semm to be able to learn from past mistakes. Our high level testing is based on our specifications. At one point we were considering to try BDD.
You can use it tactically like this. It is not as good as having a proper automated test strategy based on a combination of acceptance testing and unit testing, but BDD style acceptance tests are much easier to retro-fit to a system that wasn't written with testing in mind.
Excellent description & argument. Also, major inside joke points for using the infamous Oracle security hole "scott/tiger" demo account! I guess kids today just didn't get that ;)
I was about to comment on exactly the same thing, but you beat me to it! 😂
Is there any open source project with good tests using BDD?? I would like to study this with some code as reference
Sticking with the example you gave about adding your book to the shopping cart and asserting that it is there. Where is the step that adds the book(s) to the list of available books to choose? Should those be added to it or is there just a set of books that are known to be in there? Would this test break when the business says we want to sort same titled books a certain way so the OG author gets seen (first|last); or what if it was like ebay and distance mattered... These other details business frequently talks about but then I get into that fine line of having too much details or not enough details in my test... and if it wasn't enough and I add it then I have to go and add this information to all my other tests that I've just gone and broke.... still I wish that my current client used BDD instead of nothing. I miss getting to write acceptance tests.
Love to hear tales some of "When IDEs go wrong" and "When Text Editors go wrong"
Very good video overall, if for nothing else than to give some food for thought, like many of your videos. Often enough I find the decision on how to approach development isn't as important as the shared understanding of why that decision has been made, and what other options have been considered and the reasons they were rejected.
edit: I find a comparison between BDD and Hungarian Notation somewhat interesting, as the idea of both, as far as I can tell, is to represent intent and not specifics, and both are used incorrectly (granted, much of the latter is better described using type systems)
Can you do a video on the language that allows for test specification in "plain English"? I have never seen it before and it looks like magic to me. The idea of de-coupling *what* the code should do from *how* it should do it is really good, but I don't see how these "wordy" tests help.
Surely specify what these English words mean (which functions in code they should call), so that you can actually execute the test on a machine, and then that specification of the words will be coupled to the code instead of the entire test.
You could just as easily write a normal function that specifies the behavior and call that instead. The test would be just as readable and decoupled, but now you have the added benefit of being able to call that function in your code.
You mentioned in the video that these tests don't mean BDD and don't guarantee good tests with good decoupling, so I guess it is just another tool that can be used well or poorly.
I have a few videos that touch on aspects of that already. I am working on a training course that will go into a lot more detail later in the year.
Try some of these:
"DDD with BDD" ruclips.net/video/Ju50D11EIoE/видео.html
"Real World BDD": ruclips.net/video/9P5WG8CkPrQ/видео.html
"Better Exec Specs": ruclips.net/video/5CXSEINRojM/видео.html
"How to Write Acceptance Tests": ruclips.net/video/JDD5EEJgpHU/видео.html
When? Always!
We don’t need no thought control.
If BDD does should no focus on testing every input entry, will it not open a security issue where incorrect input or malicious input could compromise the system?
How can BDD help us in preventing security issues? Or am I asking the wrong question?
No, you cover that with other forms of testing. Yes you are asking the wrong question because you are limiting the answer to only BDD. If you reframe the question as something more like "how do we prevent security issues?" there are lots more, and better, answers. I am thinking of doing another video on this topic, but I do have this one: ruclips.net/video/NdvMUcWNlFw/видео.html
When my team built a financial exchange, we did all sorts of security testing, only a small fraction of it was through BDD style acceptance tests.
There are some really good arguments for using BDD. Thanks, I am taking notes :)
Though I might write “Given I login as a Finance Officer” as “Given I am a Finance Officer”.
I see the requirement as: You expect a change in behaviour based on who you identify as. The fact that you need to prove who you are is not relevant to this test.
Thank you for great material. I've gathered in my public repository all intresting stuff about BDD (links to books, articles, talks). Your movie and John Ferguson talk is another material fom the collection.
Could you post the repo URL please?
Im confused between BDD specs and user stories . Isn’t it the same goal for both
My real answer is "it depends", mostly not the same, but sometimes it is. There are usually more specs than stories. The stories tend to be general "pay by credit card" and the specs tend to be more generic "pay £10 with a personal Mastercard" and "pay £10 with a business Mastercard", sometimes this is called "Specification by Example".
There's a grey area, you may decide to split these out into separate stories to organise the work, "Pay by personal credit card" and "Pay by business credit card" for example. So they are certainly closely related.
Nice little jab of YT's decision to hide the public dislike count BTW ;)
Why is it called Domain Specific Language instead of Domain Language? Doesn't the word domain already imply something specific?
I guess people like TLAs (three letter acronyms). I use it because it is the common term.
@@ContinuousDelivery It's confusing, because my mind is used to thinking of DSL (digital subscriber line) as a commonly used acronym for data communication technology.
@@realdeal968 YAA...
what is your opinion on applying BDD at all levels of testing?
Dave just said explicitly at the end of the video that BDD is not to be applied to all levels of testing, but mostly at the E2E level, executing the specification against the fully deployed system. There are always exceptions, of course, like if you have some core library that contains a lot of important business logic, you could write executable specification for it in the form of unit tests, but then they would not be called unit tests anymore, I suppose.
BDD belongs at the top (or near top) of the test triangle. If you implement BDD for a level lower than the top, you are looking at a very large maintenance overhead. Use a good unit test framework for unit and integration tests. Use a good unit test framework for the 'corner case' or 'every case' testing. Use BDD for the documentation, support reference, and UAT part of the project. BDD intention (or at least one of the intensions) is to allow the team to decouple behavior from implementation.
I think that this depends on what you mean by "BDD", there are, at least, two different interpretations. I think that today, most people think of BDD as focused on, what I'd call, acceptance testing, high-level functional tests that act as executable specifications for the behaviour of a system. That's the kind of BDD that this video is talking about.
But that wasn't what was meant when BDD was invented. It started out attempting to describe a better way to teach TDD. I talk about that in this video: ruclips.net/video/Bq_oz7nCNUA/видео.html
I think that this second version is more generally applicable, and sadly, often overlooked. It certainly deeply informs my approach to TDD. It doesn't require the complexity, or tools, that the functional testing stuff does, which I guess is why the idea didn't gain as much ground, people love tools! Ultimately its more important though.
It says focus your tests, even your unit tests, on only the desirable behaviour of your code, not its implementation. Even at the level of a simple unit test, write it as a tiny specification of what you want the code to do, not how it does it. So in this form, BDD is nearly the whole testing triangle.
@@ContinuousDelivery "Even at the level of a simple unit test, write it as a tiny specification of what you want the code to do, not how it does it. So in this form, BDD is nearly the whole testing triangle." I agree. The issue I have encountered with that approach is buy in. From experience, BDD buy-in at the 'higher' level of the test triangle has been more palatable to teams that have not used BDD. We have to pick our battles. Per the original comment, TDD at all levels of testing is something to aim for. And thanks for your reply.
The greatest benefit of BDD is twofold -- to extract the business value from across multiple disciplines, while also forming an ubiquitous language that enables efficient ongoing communications. That can be done very well (even online) with the 4-color Post-It note "discovery" sessions. Then the developers can "formulate" the BDD scenarios from that, which will apply nicely to acceptance testing.
I also use BDD-style tests (in C++ using the doctest framework) even when designing and implementing library code. Generally, we don't want developers (including me) to create the business logic in a vacuum, because we might make the wrong thing, or add low-value features. But if I'm just writing some tool or module, like I/O, adapters, ADTs, data transformations, algorithms, etc., then it is just to create a self-contained module to support some greater business value(s). It's an implementation detail from the business POV, but it's still something that I want to clearly exercise and demonstrate with concise tests (executable specs), so I know it works in the present, everyone else can see how it works, and any breaking changes in the future will be not only detected, but pinpointed immediately, with an error message that presents the full context.
interesting. this has me curious about what Behavior Driven Development is. it's a new topic to me
are there any takes on BDD frameworks aiming on C++ development?
I don't think that you need a "framework" my preference is to create your own "Internal DSL" hosted in the language that you are using to develop the system. There is a CPP version of Cucumber, I have never used it but take a look here: github.com/cucumber/cucumber-cpp
@@ContinuousDelivery writing anything that is not directly related to the business problem introduces accidental complexity. And commercial companies neither have time nor money to pay for something that is not directly related to the domain.
Thanks for the link
Amazing, as always
Lol! Few times watching this video I paused it because I want to hit the Like button, and then "Damn, I already Liked it" :)
8:44 It'd be nice if you could put these things on the full screen, if only for a second.
Think of the accessibility man!
We don't need authentication, we don't need no thought control
this channel is a godsend 🙏🥰😊👍
Low/No-code automation frameworks will replace BDD in less than 10 years for acceptance testing. And just for one reason: the cost of change is almost zero, you don't need anything else. It is much easier to keep a coherent regression suite and to do analytics.
Why do you want to code a test beyond the integration test? I'll never understand that to be honest ... BDD ends always as an infinite number of microtests, which nobody can maintain and absolutely useless.
I can see the usefulness of BDD in defining executable specifications especially for web and graphical user interfaces, but what about APIs, backend applications, and microservices development where most test cases are likely one or more steps away from actual users of the system? Oftentimes the specifications end up writing implementation details instead of a broader behavior-focused definition which makes sense because we don't want ambiguity when testing these backend interfaces.
It doesn't really change the value or the approach. The goal is to express the need not the implementation. This is good for any SW. If your SW is providing "end-user" level services you can use exactly the same specification, but translate "placeOrder" or whatever else the biz concept is into a call to an interface.
If your SW is rather more divorced from end-user interactions, then you treat the programmers of services that use your service as the "users". This is more difficult to do well, because if you are used to the bad habits of specifying the solution in your requirements and tests, it is even easier for you to fall back into those bad habits. So need to work harder to keep your specs clean of "solution", but it still works extremely well. I did this with a team that was writing low-level firmware for a scientific device and it worked very well indeed.
@@ContinuousDelivery It is particularly challenging indeed. And it gets worse. In backlog grooming/refinement sessions, we tend to break down/flesh out big item user stories into smaller ones so imagine the constant reminder we get not to fall into that trap, which is silly knowing how programmers think. Thank you for the reply, Dave.
"login" is about authentication, not authorisation. Authorization happens only after the user was authenticated.
Otherwise, as presented, BDD sounds like computer science serving the real need of real people, unlike, say, cryptocurrency..
The test was testing wether the user could access something after they had logged in. Authorisation is the real test. But I am nerding out here, I may well have misspoke :)
I thought this video was gonna be about psychology
A common mistake. The name does implies psychology, also the authors of BDD have said they didn't know that BDD was a mental disorder at the time. It was a confusing time googling for stuff in the early days of BDD.
to BDD or not to BDD that is the question.
...and the answer is...
Yes! Do it!
You should replace "button" by "counter" in the sentence "RUclips needs to bring back the dislike button soon".
Great session again, but it's not "authorize", it's "authenticate" (5'54")..
Look at the example again 😁
When Goes BDD Wrong. My dudes! heh
When goes BDD wrong 😂