In this video, we're going to talk about how we can use data tables to implement many different scenarios in one. We're going to create an outline of a scenario, where we're going to have parameters in that outline that we can fill in with the examples, and in so doing it's going to allow us to define a whole sequence of test cases, using the same structure scenario. So previously, we've defined some scenarios for cooking. So, we set a certain amount of time for the microwave to cook, and then we let a certain amount of time elapse, and then we check the status of the microwave. Well, there are lots and lots of values we could choose. We could start from timeToCook being 0, or 10, or 100, or 1,000, and these scenarios look almost exactly the same. So, we were able to buy ourselves a little bit of benefit by introducing Lists, so that we could press all the keys at once. But, we still have a lot of code that looks awful similar between these scenarios, and this happens all the time. So, what we'd really like to have is something called a scenario outline, which says, I want to do this operation for this set of parameters, and this set of parameters, and this set of parameters. And, we can add to that without having to define the same looking scenario over and over again. So, let me give you an example of that, and it's quite a bit of typing, so I'm just going to pop over to the description I have here, and then I'll explain it. So, I'm going to put this into my program. So, it differs from a scenario in that we have added an additional keyword which is "Outline", and it isn't quite as specific as a scenario, it says we cook for different amounts of time. So, we're going to press some keys, in this case we're not using a list, but the interesting thing is that you're starting to see these bracketed names, and these are going to be turned into parameters. So, we can say "When <time> seconds elapse", and we can fill in the value for "time" later, and "digits reads <digits>", and "mode is <mode>". So, how do you think we're going to fill in these parameters? Well, if you guessed data tables you have it right. So, what we do is we then provide a set of examples, and the column headers, which indicate what the columns are, have to match the parameter names. So, we have "time", "digits", and "mode". And now, we can define a sequence of tests that all share the same structure, but are testing different values for each of the parameters. So, when 5 seconds elapse, if we started from 20 seconds the digits would be "0015" seconds, and the mode should still be "cooking", because we haven't reached "0000". And, we can do this all the way up until we reach 20 seconds. At that point, the digits should be "0000" and we should quit cooking. So the mode should go back to "setup". And anything beyond 20, we should also see "0000" digits, One thing I have to do is I have to generalize the mode. So, in the previous steps, I have said "the microwave is in the cooking mode". And, so I've written a specific step definition, that only allows it to be in the "cooking" mode. But in this case, I want to have an arbitrary mode. I want to be able to say "cooking", or "setup", or "suspended". And so, I'm going to actually have to write a new step definition. Let's see, and so, that one I will actually go out and grab. You know what though? I'll make it match this, and I'll just generalize it, because that's kind of a nice thing you can do with scenarios as well. Okay. So, we have moved "mode" into a parameter here, and what is going to happen is that it's going to fail because not always is the mode parameter going to be "cooking", and the step definition that we have expects the String "cooking". Oh! Yeah, there it didn't fail. Good. So, everything is as expected. So now what we need to do, is we need to generalize this step definition. So, previously we were just looking to see if the mode was "cooking", but now we want to be able to check whether it's an arbitrary mode. So, how do we do that? Well, we introduce pattern. So, what we're going to do is we're going to say, "well, it's going to be ... we know it's going to be a word, so we'll look for characters and we'll look for one or more. So, it's going to be "in a (word) mode". And, now that we're looking for an arbitrary mode, we want to get rid of "cooking" in the title of the method, and rather than checking that the "mode" is equal to "cooking", one thing we could do, is we could actually return toString() here, and then we could check to see whether or not that was equal to our "String theMode". Now we go back, we build again, and everything passes. Okay. So, now we've been able to use a Scenario Outline to make a sequence of tests, we've been able to generalize an existing step definition to work with parameters, and we've added new step definitions that are parameterized. So, now we have all the tools that we need to make rich and concise Gherkin specifications that Cucumber will execute, and we have self-documenting requirements that turn into test cases. So, this concludes the exploration of Cucumber and Gherkin that we'll do for this course.
