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>:
> 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.
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);
2008/8/30 Olof Bjarnason <olof.bj...@gmail.com>:
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
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,
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
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
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
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
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?
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?
--
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