1 00:00:07,529 --> 00:00:11,670 After watching this video, you will be able to define behavior driven development (BDD), 2 00:00:11,670 --> 00:00:17,680 explain how BDD can drive customer expectations, and describe the key benefits of BDD. 3 00:00:17,680 --> 00:00:21,580 Behavior driven development (BDD), as its name implies, focuses on the behavior of the 4 00:00:21,580 --> 00:00:24,390 system as observed from the outside in. 5 00:00:24,390 --> 00:00:29,480 This is different from test driven development, which focuses on the minutia of how the system 6 00:00:29,480 --> 00:00:30,480 works inside. 7 00:00:31,044 --> 00:00:36,410 BDD is great for integration testing to see if all of the components are behaving together. 8 00:00:36,410 --> 00:00:38,989 It forces you to think "from the outside in.” 9 00:00:38,989 --> 00:00:43,684 In other words, you implement only those behaviors that contribute most directly to business 10 00:00:43,684 --> 00:00:44,684 outcomes. 11 00:00:44,899 --> 00:00:50,859 One of the advantages of BDD is that it describes behaviors in a single notation, which is directly 12 00:00:50,859 --> 00:00:55,050 accessible to domain experts, testers, developers, and customers. 13 00:00:55,050 --> 00:00:59,120 This improves communications across the team. 14 00:00:59,120 --> 00:01:03,969 If we compare BDD to TDD we see that they are coming from opposite directions. 15 00:01:03,969 --> 00:01:06,931 BDD describes the behavior of the system from the outside in. 16 00:01:06,931 --> 00:01:09,960 It is looking at the system as a consumer of it would. 17 00:01:09,960 --> 00:01:14,020 While TDD tests the functions of the system from the inside out. 18 00:01:14,020 --> 00:01:18,479 It is making sure that each component is working correctly while BDD is making sure 19 00:01:18,479 --> 00:01:21,799 that they all work together at a higher level. 20 00:01:21,799 --> 00:01:26,920 Put another way, BDD is ensuring that you are building the right thing. 21 00:01:26,920 --> 00:01:29,880 Do you have the right set of capabilities and these behaviors? 22 00:01:29,880 --> 00:01:33,369 TDD is ensuring that you are building the thing right. 23 00:01:33,369 --> 00:01:37,380 Does each feature perform the task that it was intended to? 24 00:01:37,380 --> 00:01:42,439 The workflow starts with the developers, testers, customers exploring the problem's domain 25 00:01:42,439 --> 00:01:48,450 and collaborating to produce concrete examples that describe the behavior they want. 26 00:01:48,450 --> 00:01:51,850 They document these behaviors using a language known as Gherkin. 27 00:01:51,850 --> 00:01:56,970 It is a natural language representation that I will talk about in a moment. 28 00:01:56,970 --> 00:02:01,750 Next, the team uses a BDD tool like Behave for Python, or jBehave for Java, or Cucumber 29 00:02:01,750 --> 00:02:06,509 for Ruby, to run these examples as automated acceptance tests. 30 00:02:06,509 --> 00:02:10,610 As the team works on the solution, the BDD tool tells them which examples are implemented 31 00:02:10,610 --> 00:02:13,790 and working and warns them about the ones that aren’t. 32 00:02:13,790 --> 00:02:19,250 Before you know it, you have one document that is both the specification and the tests 33 00:02:19,250 --> 00:02:22,000 for your software. 34 00:02:22,000 --> 00:02:27,239 Gherkin is an easy-to-read natural language syntax that uses a familiar Given... 35 00:02:27,239 --> 00:02:28,239 When... 36 00:02:28,239 --> 00:02:29,640 Then... syntax. 37 00:02:29,640 --> 00:02:33,379 Gherkin is easily understandable by both technical and non-technical people. 38 00:02:33,379 --> 00:02:36,980 If you're wondering where the name Gherkin came from, the original tool that used this 39 00:02:36,980 --> 00:02:42,569 syntax was called Cucumber, and Gherkin is a pickle and pickles are made from cucumbers. 40 00:02:42,569 --> 00:02:45,900 Tools have a way of producing funny names like that. 41 00:02:45,900 --> 00:02:49,019 Here is how the Gherkin syntax is used. 42 00:02:49,019 --> 00:02:50,550 Given some context. 43 00:02:50,550 --> 00:02:55,540 This is setting up the context or the precondition that sets the stage for the test. 44 00:02:55,540 --> 00:03:00,599 The purpose is to put the system in a known state before the user (or external system) 45 00:03:00,599 --> 00:03:02,629 starts interacting with it. 46 00:03:02,629 --> 00:03:04,560 When some event happens. 47 00:03:04,560 --> 00:03:09,000 This is the principal action or actions that describe what is being performed. 48 00:03:09,000 --> 00:03:13,890 This is what takes you from the initial state to the new observed state. 49 00:03:13,890 --> 00:03:18,180 Then some testable outcome or behavior is validated. 50 00:03:18,180 --> 00:03:20,269 Then is used to observe the outcomes. 51 00:03:20,269 --> 00:03:24,917 The observations should be related to the business value or the benefit of the feature. 52 00:03:24,917 --> 00:03:28,630 And is used for continuations. 53 00:03:28,630 --> 00:03:30,010 Given this And that… 54 00:03:30,010 --> 00:03:31,930 Then this And that… and so on. 55 00:03:31,930 --> 00:03:36,730 It gives you a natural way of adding more context, events, or outcomes. 56 00:03:36,730 --> 00:03:40,409 Let's look at an example from a retail store. 57 00:03:40,409 --> 00:03:45,430 These are called feature files or feature documents and you will have one feature per 58 00:03:45,430 --> 00:03:48,409 document and many scenarios describing this feature. 59 00:03:48,409 --> 00:03:53,879 There is only one scenario in this example, but there could be certainly more to cover 60 00:03:53,879 --> 00:03:55,659 all of the permutations. 61 00:03:55,659 --> 00:03:58,560 This feature is called “Returns go to stock.” 62 00:03:58,560 --> 00:04:03,629 This feature is described by the behavior of the system when a customer returns an item 63 00:04:03,629 --> 00:04:04,989 that they have purchased. 64 00:04:04,989 --> 00:04:10,659 Notice that it uses the "As a," "I need," "So that" syntax; we use this in writing our 65 00:04:10,659 --> 00:04:11,780 user stories. 66 00:04:11,780 --> 00:04:14,989 You can think of this as a user story with acceptance criteria, where the acceptance 67 00:04:14,989 --> 00:04:17,549 criteria are the scenarios. 68 00:04:17,549 --> 00:04:21,820 This first scenario is called “Refunded items should be returned to stock.” 69 00:04:21,820 --> 00:04:26,320 It reads as follows: Given that a customer previously bought a black sweater from me, 70 00:04:26,320 --> 00:04:30,820 And I have 3 black sweaters in stock, when they return the black sweater for a refund, 71 00:04:30,820 --> 00:04:33,890 Then I should have 4 black sweaters in stock. 72 00:04:33,890 --> 00:04:35,740 It's fairly straightforward. 73 00:04:35,740 --> 00:04:40,000 Your stakeholders should be able to look at this and say, "Yes, this is how returned 74 00:04:40,000 --> 00:04:41,410 items to stock works." 75 00:04:41,410 --> 00:04:43,949 Or maybe, "Here is another way it could happen." 76 00:04:43,949 --> 00:04:47,890 Then you would document a new scenario for the "Returns go to stock" feature. 77 00:04:47,890 --> 00:04:53,699 The point is, your stakeholders are actually helping you define the behavior of the system 78 00:04:53,699 --> 00:04:58,560 in a formal syntax that you can now execute test cases against. 79 00:04:58,560 --> 00:05:02,850 Let me say that again: You can actually execute test cases against 80 00:05:02,850 --> 00:05:03,949 this document. 81 00:05:03,949 --> 00:05:09,530 BDD tools like Behave and Cucumber can consume this document with no further editing or manipulation 82 00:05:09,530 --> 00:05:15,040 and execute test cases to prove that the system does indeed exhibit the behavior. 83 00:05:15,040 --> 00:05:18,319 That will put a smile on your developer’s face. 84 00:05:18,319 --> 00:05:22,670 This is why I add acceptance criteria to every user story. 85 00:05:22,670 --> 00:05:28,220 I use the Gherkin syntax to define the acceptance criteria in the user stories that we write. 86 00:05:28,220 --> 00:05:32,220 There is no arguing over the definition of "done" at the end of a sprint. 87 00:05:32,220 --> 00:05:33,220 It’s indisputable. 88 00:05:33,220 --> 00:05:37,550 The code either does or does not exhibit this behavior. 89 00:05:37,550 --> 00:05:42,690 BDD improves communication among the team members like developers, testers, product 90 00:05:42,690 --> 00:05:45,210 owners, and other stakeholders. 91 00:05:45,210 --> 00:05:50,229 It leads to more precise guidance on how the system should behave. 92 00:05:50,229 --> 00:05:55,630 It does this by providing a common syntax that is close to everyday language and has 93 00:05:55,630 --> 00:05:58,139 a shallower learning curve compared to TDD tools. 94 00:05:58,139 --> 00:06:05,340 Tools targeting the BDD approach generally afford the automatic generation of technical and 95 00:06:05,340 --> 00:06:09,220 end user documentation from the BDD feature specification. 96 00:06:09,220 --> 00:06:14,620 Having a clear behavior visibly results in higher-quality code, which reduces the cost 97 00:06:14,620 --> 00:06:17,280 of maintenance and eliminates the risk. 98 00:06:17,280 --> 00:06:22,780 Finally, with BDD acceptance criteria you are already converted to user stories and test 99 00:06:22,780 --> 00:06:25,430 scenarios before the actual development. 100 00:06:25,430 --> 00:06:30,257 Thus, automating test cases can start creating test processes even before the product is 101 00:06:30,257 --> 00:06:31,507 tested. 102 00:06:32,729 --> 00:06:36,639 In this video, you learned that BDD focuses on the behavior of the system 103 00:06:36,639 --> 00:06:37,979 from the outside in. 104 00:06:37,979 --> 00:06:41,060 It looks at the system as a consumer of it. 105 00:06:41,060 --> 00:06:46,290 BDD uses an approachable syntax that everyone can understand. 106 00:06:46,290 --> 00:06:51,410 Key benefits of BDD include improvement in communications, a common syntax, and acceptance 107 00:06:51,410 --> 00:06:53,797 criteria for user stories.