Next stop is explicit versus implicit and imperative versus 
declarative, so different types of scenarios and different ways 
to think about scenarios. The motivation slide that we try to 
start off everything with is are all the requirements come 
directly from user stories? We said scenarios are from three to 
eight. How do we keep them closer to three rather than more like 
eight so that it doesn't take as long to write them, it doesn't 
take as long to understand them? In terms of the outcome from 
the user stories, that gets referred to as explicit versus 
implicit scenarios. The explicit ones are the things that come 
directly from the user, from the customer. They are basically 
acceptance test. We added search TMDD. That is to list all the 
movies. That's examples of things that the customer want to see 
in the page. Things that the customer doesn't maybe care about 
would be like that in example when you list them, you list them 
in the order that they were entered or in alphabetical order or 
chronological order by when the movie came out. Maybe the 
customer doesn't really care so you're going to have to figure 
out what to do. That's an example of an implicit story. Just 
keep that in mind. There are some things that come directly from 
the three by five card and some things you're going to figure 
out, the customer asking questions all the time. Now when we've 
been writing these things up, we've been writing in what's 
called an imperative way. Here's a given state and here's a 
sequence of steps to get us to this next state so we're ready to 
do the test that we want to see, to see if it's doing acceptance 
test as we want to do. If a lot of your user stories are 
imperative, a lot of them will have the very same steps. Once 
again, [ inaudible 00:01:55] goes off, we see a lot of the same 
things. There must be some way to try and avoid this because we 
want to not repeat ourselves. Basically, the way to try and do 
this is what's called declarative, declarative approaches which 
is that is we're going to try and say the state we want it to 
be. If you think about declarative programming languages versus 
imperative programming languages, that's inspirations of these 
names. This should take a lot fewer steps. Let me try and make 
this concrete. I'm going to talk about listing the movies 
alphabetically. I'm going to show you first how you do it 
imperatively in a lot of steps and then show you how to do 
declaratively. How are we going to say it's in alphabetical 
order? What we're going to do is go through these steps. Here is 
the imperative approach. Given I'm on the Rotten Potatoes home 
page and then I follow add a new movie and then I fill in the 
title Zorro and press save changes, then that should be on the 
Rotten Potatoes home page and add a new movie and add the title 
Apocalypse Now and then give it a rating and I save changes. I 
should be in the Rotten Potatoes home page and I should see 
Apocalypse Now before Zorro. That was a lot of steps to write, 
to go through, to create changes from the state that I wanted 
was originally into the state of one of these so I could do this 
one test here. That's the behavior I'm after, that it's in 
alphabetical order. Remember the BDD, the B in BDD is about 
behavior. It seems like it's a little weird that we're trying to 
describe behavior. We do it imperatively like you're 
implementing it. The idea here is to think of it as making a 
domain language, not a domain specific language but a domain 
language. You try and come up, think of it in terms of your 
applications, in terms of the feature you want to do and the 
concepts. This is just an informal language. You're trying to 
write the declarative steps in this language. Your step 
definitions will define those. How about a declarative version 
of the scenario for keeping things in alphabetical might look 
like. The feature's the same. View the list after adding a 
movie. Given I have added Zorro with a rating, that's just 
describing the state that I wanted it to be. Given I have added 
Apocalypse Now with a rating, then I should see Apocalypse now 
before Zorro. That's a lot better. That's three steps versus 15 
steps. One step of those three steps is behavior. That's a lot 
better. Declarative scenarios are focused on behavior being 
tested rather than steps needs to set up the test. How are we 
going to do this? The way we're going to do this is some more 
step definitions. The next slide gives you an example. Here's a 
step definition, [ inaudible 00:04:49] declaratively. Basically, 
you're taking the single step and turning it into a bunch of 
smaller steps. Remember we said a step is like a method call and 
a step definition is like a method definition. You could think 
of that just like we've done it. You do this hierarchically. You 
use code. Similarly, you can do that with steps and step 
definitions. This example on the left, that's handling the given 
statement, given I want to add this movie and it takes these 
steps, these more imperative steps in the side. The idea here is 
that you may get started writing imperatively but you should 
start minding them to try and make step definitions or method 
definitions out of them so you could [ inaudible 00:05:33] so 
you don't have to write as much codes. You'll start off 
imperatively and hopefully migrate to declaratively. With that, 
we're ready to see how this works. Let me read this. What's true 
about these types of scenarios, implicit and explicit, and 
declarative versus imperative. Explicit requirements are usually 
defined with imperative scenarios and implicit requirements are 
usually defined with declarative scenarios. Explicit scenarios 
usually capture integration tests. Declarative scenarios aim to 
capture implementation as well as behavior. All of these are 
false. 
