Given When Then to be or not to be
Joe Ocampo
Given, When, Then as made popular from Dan Norths initial post on BDD has become a somewhat challenging aspect for me when I talk to people about BDD.
For the most part people tend to immediate understand "When this action or something occurs" , "Then this should happen".
But the "Given" completely throws them. I think it revolves around common everyday vocabulary nuances. Meaning we don't communicate like politicians we communicate like people.
So lets look at the goal of each construct:
Given == Establish an initial context state for the concerned object
When == Establishes intended actions and/or mutations against the concerned object
Then == Conveys the intended behavior and/or ability that the concerned object should/not be eliciting
Consider a common user request:
// when my wallet is out of my money then it should not let me use my credit card
I see a statement like this and I have to think about the goal of what the user wants. He wants money from his wallet but because his wallet is out of money, he has a rule to protect from using his credit card. Because I understand BDD I can translate this too.
Describing my wallet
- Given my wallet is out of money
- When I need money
- Then it should not let me use my credit card.
My question is, is there anything we can do to decrease the amount of "Thought Effort?" that goes into figuring out the context.
Dan North
It might help to think of "Given" as "If".
If my wallet is out of money
[When I go to take $30 out]
Then it shouldn't give me $30
In your example there is an assumed phrase - called an ellipsis if you're a linguist - whereby the "when" is implied. When you say "then it shouldn't give me $30" it implies you must have tried to get $30, so you don't need to say explicitly that you tried.
Here's another example: I went to the shop and the bowling alley (the ellipsis is "I went to" in the second clause - you are actually saying: I went to the shop and I went to the bowling alley). Now although this works in English - and in other similarly-structured languages - it obviously won't play well in an explicit scenario description.
That's part of the tester role in BDD - helping the analyst & stakeholder articulate what they are actually trying to do and in what context it should or shouldn't work. A good tester is an expert at spotting these "gaps" - implicit steps in the scenario - and the Given/When/Then vocabulary grew out of trying to make it easier for the stakeholders and analysts to do this themselves. (Why does it happen in this scenario? What's different from the other scenario you described? What implicit context aren't you telling me about?)
Does that help?
Joe Ocampo
The ability to do that is going to force developer/analyst/testers to have a higher degree of competency in spotting those "gaps" as you put it. The GWT syntax is a tool that helps widen the entrance into that thought process.
The key aspect to what you are proposing is that this activity is very beneficial at understanding greater domain level concepts but above and below those concepts GWT begins to break down and this is where most developers find it difficult to implement.
Application plumbing code such as SQLMappers, Object Validators etc. all fall into this catagory. Where this is a buisness reason for implementing the artifactss the end user could care less on the specifics. In this case the developer or developement team becomes the user role and together they vet out GWT syntax.
Example: I need to all the upper case characters and lower case chrachters from " I Like Apples".
Looking for "ellipsis" in the statement above I can identify two context (givens) concerning the StringFilter
describing StringFilter
Given a phrase "I Like Apples"
- - When filtering uppercase letters
- - - Then it should give just the upper case letters.
- - When filtering lower case letters
- - - Then it should give just the upper case letters.
That doesn't read to well to me and it doesn't make sense when I write my specs. For non domain objects I usually imply the Given constructs so that it reads like this:
describing StringFilter
- - When filtering uppercase letters
- - - Then it should give just the upper case letters.
- - When filtering lower case letters
- - - Then it should give just the lower case letters.
thoughts?
Dan North
Analyst: I want to be able to withdraw funds from my account if I'm in credit
Tester: how much in credit? how much do you have? how much do you withdraw? how much is left afterwards?
Analyst: *sigh*
Tester: How about: if there's $100 in your account, when you withdraw $20 you should have $20 in your hand and $80 left in your account?
Analyst: yes, that's what I meant!
So at the stakeholder level you have the story narrative, and at the tester level you have concrete examples that describe how that narrative plays out in different, well, scenarios.
Dan North
This isn't just nitpicking by the tester. Often the stakeholder might say something like: well no, there wouldn't be $80 left in my account because you haven't considered the $1.50 withdrawal charge.
So it's only when you think about the specifics of the scenarios that these hidden assumptions or tacit knowledge starts to emerge, and this is often where the hidden complexity lies that blows stories out of their initial estimated scope.
Joe Ocampo
I wasn't sure if you agreed with me on these concepts?
Given a phrase "I Like Apples"
- - When filtering uppercase letters
- - - Then it should give just the upper case letters.
- - When filtering lower case letters
- - - Then it should give just the upper case letters.
That doesn't read to well to me and it doesn't make sense when I write my specs. For non domain objects I usually imply the Given constructs so that it reads like this:
describing StringFilter
- - When filtering uppercase letters
- - - Then it should give just the upper case letters.
- - When filtering lower case letters
- - - Then it should give just the lower case letters.
Dan North
So for describing something like a StringFilter, its job is obviously to filter strings, so you could almost collapse the given, when and then into a single line:
new StringFilter("I Like Apples").FilterUppercaseLetters().shouldEqual("ILA"); // or something
or in the verbose form:
// given
StringFilter filter = new StringFilter("I Like Apples");
// when
String result = filter.UppercaseLetters(); // make the behaviour you are exercising explicit
// then
AssertThat(result, Is("ILA"));
I've seen both, and I'm happy with either. A common pattern is to do the verbose one for the first one or two code examples and then drop to a shorthand for the later ones when the verbose form would be, well, verbose!
hth,
Dan
Joe Ocampo
My question is that while you code is expressive from a structural perspective documentation cannot be produced from its expressive nature that would capture GWT. Similar to how rSpec does it.
Dan North
StringFilter
- it should filter uppercase letters
- it should filter lowercase letters
You don't really care about the implementation - you can just trust that it probably does.
At a scenario level, the givens are the scenario - they are the thing that makes this scenario different from the others - so it is more relevant to have them in the documentation.
Cheers,
Dan
Olof Bjarnason
When I developed a class to trace/build polygons from a soup of lines
last week, at first had a really hard time pinning down the behaviour
of the trace; specifically it was hard to test the exact output due to
things like double-rounding and order of output.
I got a "bright moment" and relaxed the acceptance tests a little: I
thought to myself, will I not be confident with my code if I at least
tested the "discreets" involved?
So what I did was write things like:
public void Example1() {
Given()
Line_on_x_axis_from_to(0,10);
Line_on_x_axis_from_to(10,20);
When_tracing_from_x_y(0,0);
Should();
Get_removed_line_count(2);
Get_result_polygon_with_edge_count(2);
}
Instead of testing exact correctness of the result, I tested "aspects"
of the output. I think this might be things obvious to others more
versed than me in the BDD landscape, but to me this was a "profound
understanding moment".
2008/8/30 Joe Ocampo <agil...@gmail.com>:
Joe Ocampo
Yeah I think we all have that epiphany it just takes a different thought process that we are not accustomed to using. The interesting aspect is once you have that epiphany you start looking at your old test and wonder, "What was I thinking?"
Now it becomes somewhat of a second nature to look for the "Given" context of any specification I am writing.
Cheers,
JO
Chad Myers
Several times in this thread, various people have touched on what the stakeholder is doing or cares about. And it's usually:
Action
Condition -> Consequence
Condition -> Consequence
Etc
For example:
I want to withdraw $100 from my account through this ATM
If my account or the ATM are empty, I get my card back and a notice
If I'm overdrafted, the ATM keeps my card and gives me a nasty notice
If my account and the ATM have enough money, the ATM dispenses $10 0 and debits my account $101.50.
This is much more natural and, from my experience usually how the conversations go with stakeholders/domain experts.
It's also much easier to add new conditions and consequences when the SH/DE inevitably remembers "Oh yeah, I forgot one more requirement: If the user is wanted by the police, the ATM notifies authorities that they've used this ATM recently" (for example).
I've been talking with Jeremy alot about BDD lately and we've seen some BDDisms and patterns appearing in our storyteller tests. I'm thinking that Storyteller's FIT-like abilities are primed to become a natural-ish language BDD testing framework where you can define your tests with hardly any of the syntax constrants that C#, Java, or even Ruby require of you.
I plan on advocating a pattern of using the Action, (Condition->Consequence)* format rather than the GWT style.
Thoughts?
----------------------
Sent from my phone. Please excuse typos and extra characters
>> Given a phrase "I Like Apples"
>> - - When filtering uppercase letters
>> - - - Then it should give just the upper case letters.
>> - - When filtering lower case letters
>> - - - Then it should give just the upper case letters.
>>
>> That doesn't read to well to me and it doesn't make sense when I write my
>> specs. For non domain objects I usually imply the Given constructs so that
>> it reads like this:
>>
>> describing StringFilter
>> - - When filtering uppercase letters
>> - - - Then it should give just the upper case letters.
>> - - When filtering lower case letters
>> - - - Then it should give just the lower case letters.
>>
>>
>> >>
>>
>
Chad Myers
John Teague
Elizabeth Keogh
> My question is, is there anything we can do to decrease the amount of
> "Thought Effort?" that goes into figuring out the context.
I'm finding the question "Does that always happen?" is great for
discovering hidden contexts, both from business people (at client
sites) and my own secretive brain (when messing with JBehave or
personal toys).
Cheers,
Liz.
Olof Bjarnason
> Oh I like that term "tacit knowledge" :-)
>
> I wasn't sure if you agreed with me on these concepts?
>
> describing StringFilter
> Given a phrase "I Like Apples"
> - - When filtering uppercase letters
> - - - Then it should give just the upper case letters.
> - - When filtering lower case letters
> - - - Then it should give just the upper case letters.
I would have written that like this:
(Syntax highlighted version here: http://paste-it.net/public/i6b3423/)
[TextFixture]
public class Story_StringFilter
{
[Test]
public void Example1() {
Given("I Like Apples");
When_filtering_uppercase_letters();
Should_get("ILA");
}
[Test]
public void Example2() {
Given("And Oranges Too");
When_filtering_lowercase_letters();
Should_get("AOT");
}
string input, output;
private void Given(string text) {
input = text;
}
private void When_filtering_uppercase_letters() {
output = StringFilter.UppercaseLetters(input);
}
private void Should_get(string expected) {
Assert.AreEqual(expected, output);
Olof Bjarnason
http://paste-it.net/public/i6b3423/
2008/8/30 Olof Bjarnason <olof.bj...@gmail.com>:
Morgan Persson
Several times in this thread, various people have touched on what the stakeholder is doing or cares about. And it's usually:
Action
Condition -> Consequence
Condition -> Consequence
Etc
/Morgan
Chad Myers
This seems more natural to me, also. The other day we sat down and started testing and we had some functionality: “The user types a name of a tag into the box and clicks the ‘Add’ button”
But before we could start testing, we had to go through and figure out some of the contexts FIRST. As we started testing, it turns out the contexts we came up with were not quite correct/representative.
So we kept having to stop and re-think some things and every time we did, since the tests always started with Given, we had to keep refactoring the tests.
It would’ve just been easier to start with:
- User types the name of a tag and clicks ‘Add’
o If the tag already exists, do nothing
o If there is an error, notify the user
o If the tag name is invalid, notify the user
o Etc
The funny thing is, when we were planning our tests on the whiteboard, this is how we wrote them. Then we went through the task of trying to put them into GWT format and, I feel, wasted a bunch of time because it wasn’t natural with how we were thinking.
Thoughts?
-c
From:
behaviordriv...@googlegroups.com
[mailto:behaviordriv...@googlegroups.com] On Behalf Of Morgan
Persson
Sent: Saturday, August 30, 2008 7:37 AM
To: behaviordriv...@googlegroups.com
Subject: [BehaviourDrivenDevelopment] Re: Given When Then to be or not
to be
On Sat, Aug 30, 2008 at 2:58 AM, Chad Myers <ch...@chadmyers.com> wrote:
Dan North
Given ...
When ...
Then ...
When ...
Then ...
When ...
Then ...
for instance a wizard or a multi-step process. (Given I am on the landing page, when I log in then I should be on the summary page. When I select an entry then I should see the detail for that entry.)
This is especially useful for state-like systems. Given I am at State 1, when I do Action 1 then I should get to State 2. When I do Action 2 then I should get to State 3, etc.
The idea behind the Given/When/Then syntax is to get you thinking: is this actually about the behaviour (the When) or is this just about the context (the Givens)? If it's just about context I can implement it any old way I choose. I can stick data in a database, create some objects in memory, whatever works. If it's the main behaviour then I should probably drive it through the application interface.
In the very early days of scenarios in JBehave (around 2004?) I tried imposing the specific template of Given a, When b Then c, but Liz soon convinced me it was artificially restrictive, and that - as you say - a lot of scenarios simply don't work that way. (It's also what led to the idea of a "Given scenario" - using an entire previous scenario as part of the context for this one.)
So the bottom line is, do whatever works for you, but try to keep track of which bits are interesting behaviour and which are just setup.
Cheers,
Dan
Chad Myers
Dan,
Thanks for the reply. I guess what I’m thinking is:
Given…
- A user
-
Data submitted from the user
When “clicking on the ‘Add’ button”
Then [the tag should be added]
And [the user’s screen should be refreshed to show the new tag]
Given [a slight modifier to ‘Given’, i.e. the tag name is invalid]
Then [the user should be notified that the tag name is invalid]
Given [there was a system error]
Then [the user should be notified that there was an error]
Given [the tag already exists]
Then [nothing should happen]
Is it acceptable/advisable to have nested Given modifiers?
This seems more natural to me, because otherwise you’re copying a lot of setup around and you’re creating new contexts that aren’t necessarily new contexts
Jimmy Bogard
In the analysis of the story, often the conversation starts around some specific implementation or action. Before we move on, we go through the 5 why's to get back at the motivation behind the "ask". Often we wind up at a different place than the original story, if the story is focused on an implementation detail.
The other issue is that our conversations about implementations surface more than one observation concerning a certain context/action. For example, each of the action/condition pairs would be a single context, with a set of observations.
When adding a tag that already exists
- The tag should not be added to the repository
- It should return a message to the user that the tag already exists
When adding the tag results in an error
- It should not result in an exception
- It should show an error message to the user
When adding an invalid tag name
- It should not be added to the repository
- It should show an error message to the user
There are no mentions of clicking, inputs or buttons, but a higher-level user interaction description. When we analyze each context, we go through the different observations/outcomes that would make this context valid. Starting with the action is good, but I see it as only the first step.
Chad Myers
Ok, forget the clicking stuff. I agree, I was trying to keep it specific rather than get into a larger story-collection conversation. The point is, there is one context, and nested conditions. In your example, the “When adding a tag” is repeated unnecessarily. Why not next them?
Something like this?
Given:
- The user is logged in
- The user is viewing a case
When adding a tag to the case
- The tag should be added
If: the tag name is invalid
o The tag should not be added
o The user should be notified of the problem
If: there is a system error
o The tag should not be added
o The user should be notified of the problem
If: the tag already exists
o Blah blah
-Chad
Joe Ocampo
Taking your example
Given:
- The user is logged in
- The user is viewing a case
When adding a tag to the case
- The tag should be added
If: the tag name is invalid
o The tag should not be added
o The user should be notified of the problem
If: there is a system error
o The tag should not be added
o The user should be notified of the problem
If: the tag already exists
o Blah blah
Given the tag name is invlalid.....
Given that the system is in an error state...
Given the tag already exist...
As you can see the context clearly come out from the story context stream. From a story runner perspective this would work.
Now if we were using a Specification context, for instance rSpec, it would look something like this:
context "adding an invalid tag" do
it "should notify the user"
context "app is in an error state" do
it "should notify the user"
context "already exists" do
end
As you can see the Specification context focus the interaction around the "tag" itself and the context are more explicit. For sake of time I omitted the "before each" that would basically setup the user state of the tag concerns.
In the end they both accomplish the same results, although their approach may differ significantly the spirit of BDD within the GWT guidlines has been accomplished and the result is a reentrant code base that can be easily read.
Chad Myers
Joe,
Thanks for the response.
Where I’m kind of going with all this is that every time I look at BDD forced uncomfortably in the syntax of C#, Java, or even Ruby, I throw up a little in my mouth. If our goal is to be expressive about behavior and expected results, then let’s be expressive.
Is it reasonable to say that we have NBehave, JBehave, rSpec, etc because they have compilers/interpreters and it’s too difficult to build a language that is optimal for BDD? What if it wasn’t too difficult?
-Chad
From:
behaviordriv...@googlegroups.com
[mailto:behaviordriv...@googlegroups.com] On Behalf Of Joe
Ocampo
Sent: Saturday, August 30, 2008 10:57 AM
To: behaviordriv...@googlegroups.com
Subject: [BehaviourDrivenDevelopment] Re: Given When Then to be or not
to be
@Chad
Taking your example
Joe Ocampo
Chad Myers
External DSL yes, sort of.
For the end user to interact with? No.
For the stakeholder/pm/ba/whatever to VIEW? Perhaps.
-c
From:
behaviordriv...@googlegroups.com [mailto:behaviordriv...@googlegroups.com]
On Behalf Of Joe Ocampo
Sent: Saturday, August 30, 2008 11:15 AM
To: behaviordriv...@googlegroups.com
Subject: [BehaviourDrivenDevelopment] Re: Given When Then to be or not
to be
Are you referring to creating an external DSL for end user to interact with?
Joe Ocampo
Chad Myers
I’m not thinking executable stories (well, I don’t think that I am).
I’m thinking about a syntax for expressing GWT, or ACC in a more normal language. I want there to be a common way of developers writing the guts behind it that make the various statements (GWT/ACC) true/reality.
I want the people responsible for accepting the end product (determining acceptance criteria) to be able to clearly see what the ACTUAL tests are on the system using language/structure that’s easily recognizable for them (i.e. not a lot of code noise, or none at all).
I want the devs, testers, and stakeholders all using the same language to describe the action, the conditions, and the consequences (behavior and expected results).
The more I play with Fit and StoryTeller and the more I try to do BDD, the more I’m seeing that there’s a happy marriage in there somewhere.
Don’t get me wrong, I don’t like Fit very much, but I think the concept could be applicable. I think that if you have a well crafted domain model using ubiquitous language, you should be able to write something like:
>> Given the (User) is (logged in)
>> When the (User) (logs out)
>> Then the (Current Screen) should be the (Login Screen)
I know this is a bad example, but I think there might be something there and it wouldn’t involve a lot of effort writing fixtures (like Fit needs to do today) because there could be something that could understand that “Logs out” maps to the “user/logout” controller/action or something.
-Chad
From: behaviordriv...@googlegroups.com
[mailto:behaviordriv...@googlegroups.com] On Behalf Of Joe
Ocampo
Sent: Saturday, August 30, 2008 11:36 AM
To: behaviordriv...@googlegroups.com
Subject: [BehaviourDrivenDevelopment] Re: Given When Then to be or not
to be
Curious by what you mean by VIEW? I know that you know ,that I know.... sorry couldn't resist :) At some point developers are going to have to get involved and write something. What are developers writing, what are end participators viewing?
Joe Ocampo
one project I think jeremey doesn't talk about enough.
--
Sent from Gmail for mobile | mobile.google.com
God Bless,
Joe Ocampo
agilejoe.lostechies.com
"How do you benefit if you gain the whole world but lose your soul in
the process?" Mark 8:36