BDD Acceptance Testing
56 views
Skip to first unread message
heyn...@gmail.com
Mar 21, 2008, 7:41:45 AM3/21/08
to Behaviour Driven Development
Posted by Claudio Figueiredo on Alt.Net list
A nice approach to achieve a sort of BDD Acceptance Testing using
NBehave and Watin.
http://manicprogrammer.com/cs/blogs/heynemann/archive/2008/03/14/stormwind-accuracy.aspx
Having stories like this:
[Test]
public void ShouldTestSeeAction()
{
Story story = Story
.AsA("Regular User")
.IWantTo("See Action tests")
.SoThat("I can test the See action and its sub actions are
working");
story.WithScenario("User should see textbox")
.Given(I.GoTo("Default Page"))
.And(I.SeeDefaultControls)
.When("The page finishes loading.")
.Then(I.See("My Test").Message);
}
and results like this:
Story:
As a Regular User
I want to See Action tests
so that I can test the See action and its sub actions are working
Scenario 1: User should see textbox
Narrative:
Given That
I navigate to Default Page at /default.aspx
and that I see the default controls for the Default Page
When
The page finishes loading.
Then
I see the "My Test" message.
How you people fell about this?
Source: http://stormwind-svn.cvsdude.com/svn/Stormwind.Accuracy/Trunk
--
Claudio Figueiredo
jcfigu...@stormwindproject.org
Stormwind Project Commiter - http://www.stormwindproject.org
A nice approach to achieve a sort of BDD Acceptance Testing using
NBehave and Watin.
http://manicprogrammer.com/cs/blogs/heynemann/archive/2008/03/14/stormwind-accuracy.aspx
Having stories like this:
[Test]
public void ShouldTestSeeAction()
{
Story story = Story
.AsA("Regular User")
.IWantTo("See Action tests")
.SoThat("I can test the See action and its sub actions are
working");
story.WithScenario("User should see textbox")
.Given(I.GoTo("Default Page"))
.And(I.SeeDefaultControls)
.When("The page finishes loading.")
.Then(I.See("My Test").Message);
}
and results like this:
Story:
As a Regular User
I want to See Action tests
so that I can test the See action and its sub actions are working
Scenario 1: User should see textbox
Narrative:
Given That
I navigate to Default Page at /default.aspx
and that I see the default controls for the Default Page
When
The page finishes loading.
Then
I see the "My Test" message.
How you people fell about this?
Source: http://stormwind-svn.cvsdude.com/svn/Stormwind.Accuracy/Trunk
--
Claudio Figueiredo
jcfigu...@stormwindproject.org
Stormwind Project Commiter - http://www.stormwindproject.org
heyn...@gmail.com
Mar 21, 2008, 7:42:39 AM3/21/08
to Behaviour Driven Development
Posted by Owen Evans in response:
I personally believe that NBehave is a bit backwards, having readable
tests is the aim not readable output.... it should take the output as
the input. IMHO.
RSpec is much more what we really want.
O
On Mar 21, 11:41 am, "heynem...@gmail.com" <heynem...@gmail.com>
wrote:
> jcfigueir...@stormwindproject.org
> Stormwind Project Commiter -http://www.stormwindproject.org
I personally believe that NBehave is a bit backwards, having readable
tests is the aim not readable output.... it should take the output as
the input. IMHO.
RSpec is much more what we really want.
O
On Mar 21, 11:41 am, "heynem...@gmail.com" <heynem...@gmail.com>
wrote:
> Posted by Claudio Figueiredo on Alt.Net list
>
> A nice approach to achieve a sort of BDD Acceptance Testing using
> NBehave and Watin.
>
> http://manicprogrammer.com/cs/blogs/heynemann/archive/2008/03/14/stor...
>
> A nice approach to achieve a sort of BDD Acceptance Testing using
> NBehave and Watin.
>
> Stormwind Project Commiter -http://www.stormwindproject.org
heyn...@gmail.com
Mar 21, 2008, 7:43:47 AM3/21/08
to Behaviour Driven Development
Posted by me in response:
Yeah, but having readable tests was my first goal anyway...
I'm not using NBehave... Just similar syntax. I'd really love feedback
on the syntax anyway.
On Mar 21, 11:42 am, "heynem...@gmail.com" <heynem...@gmail.com>
> > Stormwind Project Commiter -http://www.stormwindproject.org- Hide quoted text -
>
> - Show quoted text -
Yeah, but having readable tests was my first goal anyway...
I'm not using NBehave... Just similar syntax. I'd really love feedback
on the syntax anyway.
On Mar 21, 11:42 am, "heynem...@gmail.com" <heynem...@gmail.com>
>
> - Show quoted text -
heyn...@gmail.com
Mar 21, 2008, 8:34:20 AM3/21/08
to Behaviour Driven Development
I just posted again in my blog about it: http://manicprogrammer.com/cs/blogs/heynemann/
On Mar 21, 11:43 am, "heynem...@gmail.com" <heynem...@gmail.com>
> > > Stormwind Project Commiter -http://www.stormwindproject.org-Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
On Mar 21, 11:43 am, "heynem...@gmail.com" <heynem...@gmail.com>
>
> > - Show quoted text -- Hide quoted text -
Brian Donahue
Mar 21, 2008, 10:08:12 AM3/21/08
to behaviordriv...@googlegroups.com
I still can't buy in to the fluent interface style. Feels too awkward for the way I think. So far, lacking Ruby-esque language conveniences, I much prefer a very thin layer (or just naming conventions) over an xUnit framework that adheres to the BDD approach.
I also agree with Scott's point about not hard-casting User Stories in code, only specifications...
I don't like the idea of spending a lot of effort (whether it's just mental exercises, or actual coding) to make my tests fit into a syntax that can then generate reports that look identical to the stories given to us by BAs or users. It feels like hocus pocus - "Hey, see? My test generates a report that says exactly what you told me, so the software *must* be what you want!" I think of BDD tests as a middle ground between the code and the original stories, directly connected to the software, not to the narratives.
I *think* Scott's point is that, as we know, the business needs at the story level are always changing, so trying to wire your tests all the way up to the story level makes for a very brittle connection. Specs are smaller discernible pieces, and more malleable, yet still give you a good indication that the software is behaving as intended.
Of course Scott can weigh in and explain what he really means :)
I also agree with Scott's point about not hard-casting User Stories in code, only specifications...
I don't like the idea of spending a lot of effort (whether it's just mental exercises, or actual coding) to make my tests fit into a syntax that can then generate reports that look identical to the stories given to us by BAs or users. It feels like hocus pocus - "Hey, see? My test generates a report that says exactly what you told me, so the software *must* be what you want!" I think of BDD tests as a middle ground between the code and the original stories, directly connected to the software, not to the narratives.
I *think* Scott's point is that, as we know, the business needs at the story level are always changing, so trying to wire your tests all the way up to the story level makes for a very brittle connection. Specs are smaller discernible pieces, and more malleable, yet still give you a good indication that the software is behaving as intended.
Of course Scott can weigh in and explain what he really means :)
heyn...@gmail.com
Mar 22, 2008, 8:15:06 AM3/22/08
to Behaviour Driven Development
I see your point of view Brian, but what I am trying to achieve is not
the output, it is a better input.
Right now I am in a project that we are using this approach of
specifying our acceptance tests as NBehave stories, and it's helping
everyone in the team to quickly understand them. Our QA loves them
since he can rapidly see if they are covering the criteria he
specified.
So what I am striving to achieve is a better way of inputing the
stories, since as of now we have to mess with a lot of delegates that
feel awkward, and I'd rather have a nice fluent interface to help me
all the way to what I want.
As I said before, I still agree with you, though that the output is
not proof that the software *must* be right. I try to think of it as a
bonus, since right now we publish the output to our Cruise build. That
output actually helps the devs (not the QA) to check if they've
covered all the QA and BA specified as acceptance criteria.
Cheers,
Bernardo Heynemann
Developer - Thoughtworks UK
heyn...@thoughtworks.com
On Mar 21, 2:08 pm, "Brian Donahue" <br...@pigeonmoon.com> wrote:
> I still can't buy in to the fluent interface style. Feels too awkward for
> the way I think. So far, lacking Ruby-esque language conveniences, I much
> prefer a very thin layer (or just naming conventions) over an xUnit
> framework that adheres to the BDD approach.
>
> I also agree with Scott's point about not hard-casting User Stories in code,
> only specifications...
>
> I don't like the idea of spending a lot of effort (whether it's just mental
> exercises, or actual coding) to make my tests fit into a syntax that can
> then generate reports that look identical to the stories given to us by BAs
> or users. It feels like hocus pocus - "Hey, see? My test generates a
> report that says exactly what you told me, so the software *must* be what
> you want!" I think of BDD tests as a middle ground between the code and the
> original stories, directly connected to the software, not to the
> narratives.
>
> I *think* Scott's point is that, as we know, the business needs at the story
> level are always changing, so trying to wire your tests all the way up to
> the story level makes for a very brittle connection. Specs are smaller
> discernible pieces, and more malleable, yet still give you a good indication
> that the software is behaving as intended.
>
> Of course Scott can weigh in and explain what he really means :)
>
> On Fri, Mar 21, 2008 at 8:34 AM, heynem...@gmail.com <heynem...@gmail.com>
> > > > > Stormwind Project Commiter -http://www.stormwindproject.org-Hidequotedtext -
the output, it is a better input.
Right now I am in a project that we are using this approach of
specifying our acceptance tests as NBehave stories, and it's helping
everyone in the team to quickly understand them. Our QA loves them
since he can rapidly see if they are covering the criteria he
specified.
So what I am striving to achieve is a better way of inputing the
stories, since as of now we have to mess with a lot of delegates that
feel awkward, and I'd rather have a nice fluent interface to help me
all the way to what I want.
As I said before, I still agree with you, though that the output is
not proof that the software *must* be right. I try to think of it as a
bonus, since right now we publish the output to our Cruise build. That
output actually helps the devs (not the QA) to check if they've
covered all the QA and BA specified as acceptance criteria.
Cheers,
Bernardo Heynemann
Developer - Thoughtworks UK
heyn...@thoughtworks.com
On Mar 21, 2:08 pm, "Brian Donahue" <br...@pigeonmoon.com> wrote:
> I still can't buy in to the fluent interface style. Feels too awkward for
> the way I think. So far, lacking Ruby-esque language conveniences, I much
> prefer a very thin layer (or just naming conventions) over an xUnit
> framework that adheres to the BDD approach.
>
> I also agree with Scott's point about not hard-casting User Stories in code,
> only specifications...
>
> I don't like the idea of spending a lot of effort (whether it's just mental
> exercises, or actual coding) to make my tests fit into a syntax that can
> then generate reports that look identical to the stories given to us by BAs
> or users. It feels like hocus pocus - "Hey, see? My test generates a
> report that says exactly what you told me, so the software *must* be what
> you want!" I think of BDD tests as a middle ground between the code and the
> original stories, directly connected to the software, not to the
> narratives.
>
> I *think* Scott's point is that, as we know, the business needs at the story
> level are always changing, so trying to wire your tests all the way up to
> the story level makes for a very brittle connection. Specs are smaller
> discernible pieces, and more malleable, yet still give you a good indication
> that the software is behaving as intended.
>
> Of course Scott can weigh in and explain what he really means :)
>
Brian Donahue
Mar 22, 2008, 12:07:20 PM3/22/08
to behaviordriv...@googlegroups.com
Hi Bernardo,
I'd be interested in hearing more about your test suite setup (from these BA/QA focused tests, down to your developer-focused tests). Couldn't find a blog for you in a quick google search, but maybe you could post an article somewhere, or just post here. Would be nice to see some more actual code and scenarios.
While the fluent interface examples I've seen to date haven't really meshed with my approach, I have never really given FIT or other story-driven test runners an honest try. I'm always interested to hear from people who are having success with that approach.
-Brian
I'd be interested in hearing more about your test suite setup (from these BA/QA focused tests, down to your developer-focused tests). Couldn't find a blog for you in a quick google search, but maybe you could post an article somewhere, or just post here. Would be nice to see some more actual code and scenarios.
While the fluent interface examples I've seen to date haven't really meshed with my approach, I have never really given FIT or other story-driven test runners an honest try. I'm always interested to hear from people who are having success with that approach.
-Brian
heyn...@gmail.com
Mar 22, 2008, 1:57:43 PM3/22/08
to Behaviour Driven Development
I'm trying to get the framework to an usable state before diving in
real usage scenarios. I'll ask my PM if I can blog about real code and
scenarios, because I think we have an NDA with the customer.
Anyway, I can create pseudo-stories that mimic the way we're using
them. As soon as I get them down I'll blog about it.
My blog is http://blogs.manicprogrammer.com/heynemann anyway. When I
blog about it I'll post here. We're definitely having a succesful
project using this approach.
Cheers,
Bernardo Heynemann
On Mar 22, 4:07 pm, "Brian Donahue" <br...@pigeonmoon.com> wrote:
> Hi Bernardo,
>
> I'd be interested in hearing more about your test suite setup (from these
> BA/QA focused tests, down to your developer-focused tests). Couldn't find a
> blog for you in a quick google search, but maybe you could post an article
> somewhere, or just post here. Would be nice to see some more actual code
> and scenarios.
>
> While the fluent interface examples I've seen to date haven't really meshed
> with my approach, I have never really given FIT or other story-driven test
> runners an honest try. I'm always interested to hear from people who are
> having success with that approach.
>
> -Brian
>
> On Sat, Mar 22, 2008 at 8:15 AM, heynem...@gmail.com <heynem...@gmail.com>
real usage scenarios. I'll ask my PM if I can blog about real code and
scenarios, because I think we have an NDA with the customer.
Anyway, I can create pseudo-stories that mimic the way we're using
them. As soon as I get them down I'll blog about it.
My blog is http://blogs.manicprogrammer.com/heynemann anyway. When I
blog about it I'll post here. We're definitely having a succesful
project using this approach.
Cheers,
Bernardo Heynemann
On Mar 22, 4:07 pm, "Brian Donahue" <br...@pigeonmoon.com> wrote:
> Hi Bernardo,
>
> I'd be interested in hearing more about your test suite setup (from these
> BA/QA focused tests, down to your developer-focused tests). Couldn't find a
> blog for you in a quick google search, but maybe you could post an article
> somewhere, or just post here. Would be nice to see some more actual code
> and scenarios.
>
> While the fluent interface examples I've seen to date haven't really meshed
> with my approach, I have never really given FIT or other story-driven test
> runners an honest try. I'm always interested to hear from people who are
> having success with that approach.
>
> -Brian
>
> wrote:
>
>
>
>
>
> > I see your point of view Brian, but what I am trying to achieve is not
> > the output, it is a better input.
>
> > Right now I am in a project that we are using this approach of
> > specifying our acceptance tests as NBehave stories, and it's helping
> > everyone in the team to quickly understand them. Our QA loves them
> > since he can rapidly see if they are covering the criteria he
> > specified.
>
> > So what I am striving to achieve is a better way of inputing the
> > stories, since as of now we have to mess with a lot of delegates that
> > feel awkward, and I'd rather have a nice fluent interface to help me
> > all the way to what I want.
>
> > As I said before, I still agree with you, though that the output is
> > not proof that the software *must* be right. I try to think of it as a
> > bonus, since right now we publish the output to our Cruise build. That
> > output actually helps the devs (not the QA) to check if they've
> > covered all the QA and BA specified as acceptance criteria.
>
> > Cheers,
> > Bernardo Heynemann
> > Developer - Thoughtworks UK
> > heynem...@thoughtworks.com
>
>
>
>
>
> > I see your point of view Brian, but what I am trying to achieve is not
> > the output, it is a better input.
>
> > Right now I am in a project that we are using this approach of
> > specifying our acceptance tests as NBehave stories, and it's helping
> > everyone in the team to quickly understand them. Our QA loves them
> > since he can rapidly see if they are covering the criteria he
> > specified.
>
> > So what I am striving to achieve is a better way of inputing the
> > stories, since as of now we have to mess with a lot of delegates that
> > feel awkward, and I'd rather have a nice fluent interface to help me
> > all the way to what I want.
>
> > As I said before, I still agree with you, though that the output is
> > not proof that the software *must* be right. I try to think of it as a
> > bonus, since right now we publish the output to our Cruise build. That
> > output actually helps the devs (not the QA) to check if they've
> > covered all the QA and BA specified as acceptance criteria.
>
> > Cheers,
> > Bernardo Heynemann
> > Developer - Thoughtworks UK
Brian Donahue
Mar 22, 2008, 3:09:57 PM3/22/08
to behaviordriv...@googlegroups.com
Added you to my blogroll. Look forward to hearing more about it.
heyn...@gmail.com
Mar 23, 2008, 12:51:42 PM3/23/08
to Behaviour Driven Development
One more post on my blog concerning this.
http://blogs.manicprogrammer.com/heynemann
Cheers,
On Mar 22, 7:09 pm, "Brian Donahue" <br...@pigeonmoon.com> wrote:
> Added you to my blogroll. Look forward to hearing more about it.
>
> On Sat, Mar 22, 2008 at 1:57 PM, heynem...@gmail.com <heynem...@gmail.com>
> > > >http://www.stormwindproject.org-Hidequotedtext-<http://www.stormwindproject.org-hidequotedtext-/>
http://blogs.manicprogrammer.com/heynemann
Cheers,
On Mar 22, 7:09 pm, "Brian Donahue" <br...@pigeonmoon.com> wrote:
> Added you to my blogroll. Look forward to hearing more about it.
>
> wrote:
>
>
>
>
>
> > I'm trying to get the framework to an usable state before diving in
> > real usage scenarios. I'll ask my PM if I can blog about real code and
> > scenarios, because I think we have an NDA with the customer.
>
> > Anyway, I can create pseudo-stories that mimic the way we're using
> > them. As soon as I get them down I'll blog about it.
> > My blog ishttp://blogs.manicprogrammer.com/heynemannanyway. When I
>
>
>
>
>
> > I'm trying to get the framework to an usable state before diving in
> > real usage scenarios. I'll ask my PM if I can blog about real code and
> > scenarios, because I think we have an NDA with the customer.
>
> > Anyway, I can create pseudo-stories that mimic the way we're using
> > them. As soon as I get them down I'll blog about it.
Scott Bellware
Mar 23, 2008, 2:58:44 PM3/23/08
to Behaviour Driven Development
Bernardo,
> I'm trying to get the framework to an usable state before diving in
> real usage scenarios.
Do you recognize risk in doing framework-first development?
-Scott
> I'm trying to get the framework to an usable state before diving in
> real usage scenarios.
-Scott
Scott Bellware
Mar 23, 2008, 3:36:40 PM3/23/08
to Behaviour Driven Development
Bernardo,
The code sample you provided has to be some of the least soluble
specification code I've seen. I'm not criticizing the quality of the
code itself, nor am I criticizing you. I think you've providing a
good and clear bit of xBehave exemplary code that demonstrates to me
personally why these frameworks are antithetical to code-level
imperatives for agile development.
The code is constrained by the framework. It's probably good clean
code all things considered, but I don't see any possible way that
fresh eyes can hit that code and derive its meaning and intent at a
glance without having to decode it first, and then assemble
understanding from the pieces.
I want specification code that allows me to glean a summary
understanding by scanning it, and if I want a detailed understanding,
I'll stop and read in detail. All the significant code in the example
given are enshrouded within API calls to the xBehave framework. The
framework itself is obscuring the meaning of the specification code.
I personally don't glean any summary understanding or xBehave-based
code. xBehave frameworks don't give me an option to read at a summary
level. Instead, I'm forced by the framework's grammar to take a more
detailed read of code that is often not of interest for my task at
hand. With xBehave-based specification code, I must first tease out
the significant bits from amidst the framework API calls, and then
cognitively re-assemble it into meaning. No matter how fast I can do
that, it's always slower than not having to do it.
Every time I read xBehave code, I can't but see examples of the
programmer mind that is cross-linking stimulation with qualities that
actually enable greater agility.
This is my own personal condemnation of programmers at the crossroads
to what I see as the next level of agility in code - so feel free to
ignore me on this, and please understand that I'm not aiming this at
you, Bernardo, I'm just using the example you provided as a onvenient
and available vehicle to make my stance more evident.
We need to be really conscious of those good vibes in our programmer
heads that are caused by interesting frameworks and cool bits of
technology. As programmers, we're susceptible to being emotionally-
triggered by programmer stuff. Those resulting emotional states
aren't directly equal to goodness in code. When we're looking at code
through the lens of a mind that has been emotionally-stimulated based
on its inherent susceptibilities and predispositions, we're at serious
risk of loosing track of the kinds of goodness that bring real agility
to our code and projects.
Last year, the notion of "soluble knowledge" and code was an idea that
I was toying with. This year, it's a part of the foundation rock that
informs my practices in agile development. I personally see xBehave
frameworks creating more dense and more opaque specification code, and
since specification code is meant to directly and rapidly communicate
understanding, I see xBehave frameworks - including those written in
Ruby - to be steps in the wrong direction for what I personally
experience as a next step in agile development's continuous
improvement.
Best,
Scott
The code sample you provided has to be some of the least soluble
specification code I've seen. I'm not criticizing the quality of the
code itself, nor am I criticizing you. I think you've providing a
good and clear bit of xBehave exemplary code that demonstrates to me
personally why these frameworks are antithetical to code-level
imperatives for agile development.
The code is constrained by the framework. It's probably good clean
code all things considered, but I don't see any possible way that
fresh eyes can hit that code and derive its meaning and intent at a
glance without having to decode it first, and then assemble
understanding from the pieces.
I want specification code that allows me to glean a summary
understanding by scanning it, and if I want a detailed understanding,
I'll stop and read in detail. All the significant code in the example
given are enshrouded within API calls to the xBehave framework. The
framework itself is obscuring the meaning of the specification code.
I personally don't glean any summary understanding or xBehave-based
code. xBehave frameworks don't give me an option to read at a summary
level. Instead, I'm forced by the framework's grammar to take a more
detailed read of code that is often not of interest for my task at
hand. With xBehave-based specification code, I must first tease out
the significant bits from amidst the framework API calls, and then
cognitively re-assemble it into meaning. No matter how fast I can do
that, it's always slower than not having to do it.
Every time I read xBehave code, I can't but see examples of the
programmer mind that is cross-linking stimulation with qualities that
actually enable greater agility.
This is my own personal condemnation of programmers at the crossroads
to what I see as the next level of agility in code - so feel free to
ignore me on this, and please understand that I'm not aiming this at
you, Bernardo, I'm just using the example you provided as a onvenient
and available vehicle to make my stance more evident.
We need to be really conscious of those good vibes in our programmer
heads that are caused by interesting frameworks and cool bits of
technology. As programmers, we're susceptible to being emotionally-
triggered by programmer stuff. Those resulting emotional states
aren't directly equal to goodness in code. When we're looking at code
through the lens of a mind that has been emotionally-stimulated based
on its inherent susceptibilities and predispositions, we're at serious
risk of loosing track of the kinds of goodness that bring real agility
to our code and projects.
Last year, the notion of "soluble knowledge" and code was an idea that
I was toying with. This year, it's a part of the foundation rock that
informs my practices in agile development. I personally see xBehave
frameworks creating more dense and more opaque specification code, and
since specification code is meant to directly and rapidly communicate
understanding, I see xBehave frameworks - including those written in
Ruby - to be steps in the wrong direction for what I personally
experience as a next step in agile development's continuous
improvement.
Best,
Scott
Scott Bellware
Mar 23, 2008, 3:50:52 PM3/23/08
to Behaviour Driven Development
Brian,
> I also agree with Scott's point about not hard-casting User Stories in code,
> only specifications...
Yes, that's my sense. User stories showing up in code is - to me -
yet another example of programmers not being conscious of becoming
emotionally triggered and hooked by technological possibilities versus
being attentive to whole team possibilities and imperatives. Writing
stories in code is - IMO - an indulgence in local optima at the
expense of the whole of software production.
Stories aren't programmer artifacts and so they shouldn't end up in
code - especially since it means that they are duplicates of the whole
team version of the artifact that lives outside of the code in order
to be accessible to, and changeable by the whole team. Stories are
meant to be fluid - they are meant to be changed much more easily than
code. When stories end up in code, they no longer take part in the
software production's visual control system, and we inevitably end up
with two versions of the truth - one version that is part of the
visual control system for the whole of the production effort, and
another one that is more frequently influencing only programmers'
understandings of the truth.
Code is a much *harder* artifact that user stories, and therefore is
the wrong medium for stories. Having multiple versions of softer
artifacts that are independently changeable will lead to multiple
versions of the truth - and in the case of stories in code - secondary
versions of the the truth that influence an entire, consistent
subsection of the whole team.
User stories in code: only programmers can be so narrow-sighted about
software development. :)
-Scott
> I also agree with Scott's point about not hard-casting User Stories in code,
> only specifications...
yet another example of programmers not being conscious of becoming
emotionally triggered and hooked by technological possibilities versus
being attentive to whole team possibilities and imperatives. Writing
stories in code is - IMO - an indulgence in local optima at the
expense of the whole of software production.
Stories aren't programmer artifacts and so they shouldn't end up in
code - especially since it means that they are duplicates of the whole
team version of the artifact that lives outside of the code in order
to be accessible to, and changeable by the whole team. Stories are
meant to be fluid - they are meant to be changed much more easily than
code. When stories end up in code, they no longer take part in the
software production's visual control system, and we inevitably end up
with two versions of the truth - one version that is part of the
visual control system for the whole of the production effort, and
another one that is more frequently influencing only programmers'
understandings of the truth.
Code is a much *harder* artifact that user stories, and therefore is
the wrong medium for stories. Having multiple versions of softer
artifacts that are independently changeable will lead to multiple
versions of the truth - and in the case of stories in code - secondary
versions of the the truth that influence an entire, consistent
subsection of the whole team.
User stories in code: only programmers can be so narrow-sighted about
software development. :)
-Scott
Pat Maddox
Mar 23, 2008, 4:07:14 PM3/23/08
to behaviordriv...@googlegroups.com
On Sun, Mar 23, 2008 at 12:50 PM, Scott Bellware <sbel...@gmail.com> wrote:
>
> Stories aren't programmer artifacts and so they shouldn't end up in
> code - especially since it means that they are duplicates of the whole
> team version of the artifact that lives outside of the code in order
> to be accessible to, and changeable by the whole team. Stories are
> meant to be fluid - they are meant to be changed much more easily than
> code. When stories end up in code, they no longer take part in the
> software production's visual control system, and we inevitably end up
> with two versions of the truth - one version that is part of the
> visual control system for the whole of the production effort, and
> another one that is more frequently influencing only programmers'
> understandings of the truth.
>
> Stories aren't programmer artifacts and so they shouldn't end up in
> code - especially since it means that they are duplicates of the whole
> team version of the artifact that lives outside of the code in order
> to be accessible to, and changeable by the whole team. Stories are
> meant to be fluid - they are meant to be changed much more easily than
> code. When stories end up in code, they no longer take part in the
> software production's visual control system, and we inevitably end up
> with two versions of the truth - one version that is part of the
> visual control system for the whole of the production effort, and
> another one that is more frequently influencing only programmers'
> understandings of the truth.
I disagree. The reason that we use customer-facing tools like FIT or
RSpec's Story Runner is precisely so we can be on the same page as the
customer. In fact, if acceptance tests are implemented in a way that
the customer can't easily verify, then that leads to the same
disconnect between customer and developer understanding, but it's
hidden instead of providing an opportunity to recognize the
disconnect. Writing stories in code isn't meant as justification for
holding our customer hostage ("no we can't change that, you said you
wanted something else before - look, it's right here in the story!"),
but to help bridge the gap between our different understandings of how
a system should behave.
Pat
Dan North
Mar 23, 2008, 5:23:54 PM3/23/08
to behaviordriv...@googlegroups.com
Hi Scott.
Sorry I'm late to the party. I've been on holiday for a few weeks with a spouse-imposed ban on computers :)
I'm not sure we're on the same page with the term "story". Let's take a step back here.
I started using the term BDD because of the problems associated with the "test"-based vocabulary of TDD. That was when I spoke to Dave Astels, back in 2003/4, who is a programmer and who had the same feelings about getting the words right.
Then I started talking to some analyst friends, and they were having the same problem with acceptance criteria, so BDD moved up the stack. (This is a fast-forward, the whole process took about 18 months.)
The important thing is the automation of scenarios as acceptance tests. (Actually with outside-in development they start as an executable specification at the application level, and then become acceptance/regression/functional/user/whatever tests. See how the testing words still keep getting in the way, at the application level?)
Not if you're doing it right. The story narrative probably lives on a wiki or in a document or on a spreadsheet on a file share or wherever the team, globally, thinks is the right place. There is probably an id, say a story number, that identifies the story.
The only thing the team cares about automating - at an application level - are the scenarios (several teams I work with still call them acceptance tests, but we have a shared understanding of what that means). This usually starts out as a paired activity between testers and devs, but over time the testers take more ownership of this.
The scenarios are in two buckets, "in progress" and "completed". Any completed scenarios should always be passing, and should fail the build if they fail. The in-progress ones can fail.
It's usually the understanding of the story that's variable, by which I mean the scope, by which I mean the set of scenarios that define "done" for this story. Code is the perfect representation for these.
I don't know what you mean by "visual control system", but on the tens of projects I have seen using BDD the continuous build runs whenever anyone changes any code (which includes any configuration or environment details) and the results are published and available to the whole team, including external stakeholders.
If this is a real effect you are seeing then I can only suggest you aren't using automated verification and continuous integration properly. I'm happy to talk about the variance you're seeing.
Ward Cunningham uses the metaphor of clay when he describes test-driven code. It is malleable and easy to change providing you have a reliable and repeatable method of validating that it still does what it is supposed to.
I want to be able to rewrite, expand, delete or move scenarios as I wish, and to be able to instantly(ish) validate my new understanding. Having a scenario decomposed into steps, where each step is either setting up, executing or verifying my application, is a very powerful model for doing this. I've also observed a number of projects where just the shift in vocabulary (to given/when/then), without any of the automation, made a huge impact on the quality of dialog between stakeholders, analysts, testers and developers on software teams.
Absolutely.
Only if the stories-in-code are the secondary artifacts. In my world they aren't.
Hang on, there are two different audiences here at different levels of granularity, namely programmers and stakeholders. (This also refers back to the "why do we need a scenario runner" thread.)
Programmers want examples. I've started calling TDD "coding-by-example", a term partly inspired by Brian Marick's work at http://testing.com/. Using a framework like rspec programmers can write:
describe CustomerRepository
it should find a unique customer by id
it should fail if it finds duplicate customers
it should find customers by partial surname
It's at the same level as an xunit test, and it's just as useless for a business stakeholder.
The stakeholders want to read stuff in their own language. They want to read scenarios, particularly edge cases, and tell you whether it's worth dealing with that edge case. (As a developer I can keep coding forever delivering ever-diminishing returns. But it's not my money.)
The scenario runner (not story runner - you don't run stories) is our shared definition of done, and what's more, our shared understanding of progress. This story comprises these 6 scenarios. When they work we're done. If your stakeholder meant something else by that story - either more or less - then scenarios are the unit of currency you can use to discuss that.
As you quite rightly said, you can express any scenario in just a regular example, or xunit test case. The reason I don't is that they are for a different audience - the stakeholder - and that it turns out the given/when/then steps are usually of a suitable granularity to be easily and frequently reused.
In fact I would go further and say that all the scenarios for a story typically have the same core behaviour (the "when"), but with different givens resulting in a different outcomes. The testers very quickly become adept in describing the differences between scenarios. "This one is like the previous one but where the card is also reported stolen. In that case the ATM should retain the card."
I really value your energy in the BDD space. I hope I can help close the gap between our understandings of what BDD is and why it works.
Cheers,
Dan
Sorry I'm late to the party. I've been on holiday for a few weeks with a spouse-imposed ban on computers :)
On 23/03/2008, Scott Bellware <sbel...@gmail.com> wrote:
Brian,
> I also agree with Scott's point about not hard-casting User Stories in code,
> only specifications...
Stories aren't programmer artifacts and so they shouldn't end up in
code
I'm not sure we're on the same page with the term "story". Let's take a step back here.
I started using the term BDD because of the problems associated with the "test"-based vocabulary of TDD. That was when I spoke to Dave Astels, back in 2003/4, who is a programmer and who had the same feelings about getting the words right.
Then I started talking to some analyst friends, and they were having the same problem with acceptance criteria, so BDD moved up the stack. (This is a fast-forward, the whole process took about 18 months.)
The important thing is the automation of scenarios as acceptance tests. (Actually with outside-in development they start as an executable specification at the application level, and then become acceptance/regression/functional/user/whatever tests. See how the testing words still keep getting in the way, at the application level?)
- especially since it means that they are duplicates of the whole
team version of the artifact that lives outside of the code in order
to be accessible to, and changeable by the whole team.
Not if you're doing it right. The story narrative probably lives on a wiki or in a document or on a spreadsheet on a file share or wherever the team, globally, thinks is the right place. There is probably an id, say a story number, that identifies the story.
The only thing the team cares about automating - at an application level - are the scenarios (several teams I work with still call them acceptance tests, but we have a shared understanding of what that means). This usually starts out as a paired activity between testers and devs, but over time the testers take more ownership of this.
The scenarios are in two buckets, "in progress" and "completed". Any completed scenarios should always be passing, and should fail the build if they fail. The in-progress ones can fail.
Stories are
meant to be fluid - they are meant to be changed much more easily than
code.
It's usually the understanding of the story that's variable, by which I mean the scope, by which I mean the set of scenarios that define "done" for this story. Code is the perfect representation for these.
When stories end up in code, they no longer take part in the
software production's visual control system,
I don't know what you mean by "visual control system", but on the tens of projects I have seen using BDD the continuous build runs whenever anyone changes any code (which includes any configuration or environment details) and the results are published and available to the whole team, including external stakeholders.
and we inevitably end up
with two versions of the truth - one version that is part of the
visual control system for the whole of the production effort, and
another one that is more frequently influencing only programmers'
understandings of the truth.
If this is a real effect you are seeing then I can only suggest you aren't using automated verification and continuous integration properly. I'm happy to talk about the variance you're seeing.
Code is a much *harder* artifact that user stories, and therefore is
the wrong medium for stories.
Ward Cunningham uses the metaphor of clay when he describes test-driven code. It is malleable and easy to change providing you have a reliable and repeatable method of validating that it still does what it is supposed to.
I want to be able to rewrite, expand, delete or move scenarios as I wish, and to be able to instantly(ish) validate my new understanding. Having a scenario decomposed into steps, where each step is either setting up, executing or verifying my application, is a very powerful model for doing this. I've also observed a number of projects where just the shift in vocabulary (to given/when/then), without any of the automation, made a huge impact on the quality of dialog between stakeholders, analysts, testers and developers on software teams.
Having multiple versions of softer
artifacts that are independently changeable will lead to multiple
versions of the truth
Absolutely.
- and in the case of stories in code - secondary
versions of the the truth that influence an entire, consistent
subsection of the whole team.
Only if the stories-in-code are the secondary artifacts. In my world they aren't.
User stories in code: only programmers can be so narrow-sighted about
software development. :)
Hang on, there are two different audiences here at different levels of granularity, namely programmers and stakeholders. (This also refers back to the "why do we need a scenario runner" thread.)
Programmers want examples. I've started calling TDD "coding-by-example", a term partly inspired by Brian Marick's work at http://testing.com/. Using a framework like rspec programmers can write:
describe CustomerRepository
it should find a unique customer by id
it should find customers by partial surname
It's at the same level as an xunit test, and it's just as useless for a business stakeholder.
The stakeholders want to read stuff in their own language. They want to read scenarios, particularly edge cases, and tell you whether it's worth dealing with that edge case. (As a developer I can keep coding forever delivering ever-diminishing returns. But it's not my money.)
The scenario runner (not story runner - you don't run stories) is our shared definition of done, and what's more, our shared understanding of progress. This story comprises these 6 scenarios. When they work we're done. If your stakeholder meant something else by that story - either more or less - then scenarios are the unit of currency you can use to discuss that.
As you quite rightly said, you can express any scenario in just a regular example, or xunit test case. The reason I don't is that they are for a different audience - the stakeholder - and that it turns out the given/when/then steps are usually of a suitable granularity to be easily and frequently reused.
In fact I would go further and say that all the scenarios for a story typically have the same core behaviour (the "when"), but with different givens resulting in a different outcomes. The testers very quickly become adept in describing the differences between scenarios. "This one is like the previous one but where the card is also reported stolen. In that case the ATM should retain the card."
-Scott
I really value your energy in the BDD space. I hope I can help close the gap between our understandings of what BDD is and why it works.
Cheers,
Dan
Scott Bellware
Mar 24, 2008, 2:11:25 AM3/24/08
to Behaviour Driven Development
Dan,
This is going to be one hell of a long thread if it turns into a text-
based back-and-forth. I suggest a BDD celebrity boxing match at the
alt.net open spaces event in Seattle :)
Nonetheless...
> I'm not sure we're on the same page with the term "story". Let's take a step
> back here.
For me, it goes back to RBehave and the inclusion of user story text
in program code as a primary organizing construct for executable
specifications.
> The important thing is the automation of scenarios as acceptance tests.
> (Actually with outside-in development they start as an executable
> specification at the application level, and then become
> acceptance/regression/functional/user/whatever tests. See how the testing
> words still keep getting in the way, at the application level?)
I experience this as an overly-narrow scope. In my world view, all
tests are acceptance test and the term becomes quite irrelevant. I
observe different audiences for different profiles of tests, but they
all point to the acceptability of the software for a given segment of
the audience.
> - especially since it means that they are duplicates of the whole
>
> > team version of the artifact that lives outside of the code in order
> > to be accessible to, and changeable by the whole team.
>
> Not if you're doing it right. The story narrative probably lives on a wiki
> or in a document or on a spreadsheet on a file share or wherever the team,
> globally, thinks is the right place. There is probably an id, say a story
> number, that identifies the story.
I don't use electronic copies of user stories as master copies unless
I'm forced into it by dislocated teams, and if I can't find enough
cork boards and shoe boxes to hold the index cards. I do use wiki's
for details that are too big for an index card, but rarely so, and
typically when I can't get continuous customer availability and need
to queue story background and context for an iteration batch.
> The only thing the team cares about automating - at an application level -
> are the scenarios (several teams I work with still call them acceptance
> tests, but we have a shared understanding of what that means). This usually
> starts out as a paired activity between testers and devs, but over time the
> testers take more ownership of this.
>
> The scenarios are in two buckets, "in progress" and "completed". Any
> completed scenarios should always be passing, and should fail the build if
> they fail. The in-progress ones can fail.
I feel that you are saying that you apply BDD only to the outer-most
level of an app, and to customer-facing tests. Am I reading this
right?
> Stories are
>
> > meant to be fluid - they are meant to be changed much more easily than
> > code.
>
> It's usually the understanding of the story that's variable, by which I mean
> the scope, by which I mean the set of scenarios that define "done" for this
> story. Code is the perfect representation for these.
I feel that the definition of stories is quite changeable until the
story is in an iteration backlog - and then acceptance criteria might
change, and if so drastically, the card might represent an egregious
misunderstanding as surfaced by relatively massive in-iteration
changes to its specifications.
> When stories end up in code, they no longer take part in the
>
> > software production's visual control system,
>
> I don't know what you mean by "visual control system", but on the tens of
> projects I have seen using BDD the continuous build runs whenever anyone
> changes any code (which includes any configuration or environment details)
> and the results are published and available to the whole team, including
> external stakeholders.
I see the build report on a CI server as a visual control system that
is most suitable to part of a team. Story cards marching across an
iteration board as a higher-level visual control for the iteration
remains my preference for that level of information and for breadth of
audience.
> and we inevitably end up
>
> > with two versions of the truth - one version that is part of the
> > visual control system for the whole of the production effort, and
> > another one that is more frequently influencing only programmers'
> > understandings of the truth.
>
> If this is a real effect you are seeing then I can only suggest you aren't
> using automated verification and continuous integration properly. I'm happy
> to talk about the variance you're seeing.
A voice conversation would certainly be more expedient. I'd be happy
to improve my continuous integration practices. However, I've got
doubts that the issue I'm pointing to is a CI automation issue. I see
this as an information radiation issue for a level of interest and
breadth of audience that is better served by less programmer-centric
media.
> Code is a much *harder* artifact that user stories, and therefore is
>
> > the wrong medium for stories.
>
> Ward Cunningham uses the metaphor of clay when he describes test-driven
> code. It is malleable and easy to change providing you have a reliable and
> repeatable method of validating that it still does what it is supposed to.
Sure, but code is still harder than pencil on paper.
> I want to be able to rewrite, expand, delete or move scenarios as I wish,
> and to be able to instantly(ish) validate my new understanding. Having a
> scenario decomposed into steps, where each step is either setting up,
> executing or verifying my application, is a very powerful model for doing
> this. I've also observed a number of projects where just the shift in
> vocabulary (to given/when/then), without any of the automation, made a huge
> impact on the quality of dialog between stakeholders, analysts, testers and
> developers on software teams.
Is it the change in vocabulary, or the focus specifically on
specification? I will personally become much more amenable to the
given/when/then grammar is a natural dialect of the humans on the
whole team rather than just the programmers.
> > Having multiple versions of softer
> > artifacts that are independently changeable will lead to multiple
> > versions of the truth
>
> Absolutely.
>
> - and in the case of stories in code - secondary
> > versions of the the truth that influence an entire, consistent
> > subsection of the whole team.
>
> Only if the stories-in-code are the secondary artifacts. In my world they
> aren't.
And this is where we fundamentally part methodological ways. Stories
captured in code is a thing that a programmer does looking through a
programmers perspective out onto the world. It's such a clear lens
for the programmer that he isn't even conscious of its existence.
The natural extension of putting stories in code is the story exporter
that we then use to generate story text to print out and put on an
iteration board. You'll have to go a very long way to convince me
that this isn't more programmer predisposition to technology
fetishism. Time and dialog may change my mind, but in the mean time I
remain rather attached to my low-fi perspective on software production
and necessary means of technology-supported communication and flow
control.
> > User stories in code: only programmers can be so narrow-sighted about
> > software development. :)
>
> Hang on, there are two different audiences here at different levels of
> granularity, namely programmers and stakeholders. (This also refers back to
> the "why do we need a scenario runner" thread.)
>
> Programmers want examples. I've started calling TDD "coding-by-example", a
> term partly inspired by Brian Marick's work athttp://testing.com/. Using a
extremely technical customer, at which point, we'd need some other
filtering.
> The stakeholders want to read stuff in their own language. They want to read
> scenarios, particularly edge cases, and tell you whether it's worth dealing
> with that edge case. (As a developer I can keep coding forever delivering
> ever-diminishing returns. But it's not my money.)
Sure. Agreed. But I prefer to use grammars that are more business-
natural and more English-natural than the run-on expressions I see
coming out of the given/when/then API's. Here again, you'll have to
go a long way to convince me that this is a more expressive way to
create natural specification. I find this grammar very amenable to
encoding via programmatic API, but I find it unnatural as a simple and
natural language use.
I prefer the plain old English sentences that RSpec provides as a way
to capture expression. I much prefer this over breaking up cohesive
expressiveness over multiple API calls seemingly for the purposes of
fitting natural expressiveness to a programmer's interface.
I haven't seen anything yet that I can specify with an xBehave
framework that I can't specify using an xSpec framework. With an
xSpec framework, I don't the contextually-generated documentation, but
if I'm doing outer example-driven development for primary and edge
case coverage I need to formulate the text of the specification
manually. I can live with that. I see the tradeoff as a positive one
as I see xBehave grammars to lead to sub-optimization by fragmenting
and obfuscating specification code across xBehave API calls.
> The scenario runner (not story runner - you don't run stories)
Yep. Well. Horses have left the stable on that one. I believe that
you could get them back in the stable, but the appearance of a Story
primitive as a central organizing concept in the frameworks doesn't
really help.
> The scenario runner (not story runner - you don't run stories) is our shared
> definition of done, and what's more, our shared understanding of progress.
> This story comprises these 6 scenarios. When they work we're done. If your
> stakeholder meant something else by that story - either more or less - then
> scenarios are the unit of currency you can use to discuss that.
>
> As you quite rightly said, you can express any scenario in just a regular
> example, or xunit test case. The reason I don't is that they are for a
> different audience - the stakeholder - and that it turns out the
> given/when/then steps are usually of a suitable granularity to be easily and
> frequently reused.
I try to write xUnit test names in such a way as to be demonstrative
of what the customer expressed as criteria for a story. Again, and
with all due respect for your experience and your work on tools and
your leadership, I believe that given/when/then grammar is a more
awkward form of expression and I don't believe that it is endemic too
English customer communication.
The only reason that I can see that this grammar is penetrating
business-natural communications contexts in software development
projects is that programmers are pushing it into place.
> In fact I would go further and say that all the scenarios for a story
> typically have the same core behaviour (the "when"), but with different
> givens resulting in a different outcomes. The testers very quickly become
> adept in describing the differences between scenarios. "This one is like the
> previous one but where the card is also reported stolen. In that case the
> ATM should retain the card."
Ok, but there's nothing completely germane about give/when/then
grammar that makes it more natural or appropriate to that
communication. I could just have easily used some more absolutely-
worded version of: "This one is like the previous one but where the
understanding headroom in text media like email. I have a solid track
record of really ticking people off in text, but only mildly ticking
them off on the phone. In person, I'd simply win you over to my world
view through the magic of bar napkin scribblings and impassioned
dialog over a pint or two :)
Best,
Scott
This is going to be one hell of a long thread if it turns into a text-
based back-and-forth. I suggest a BDD celebrity boxing match at the
alt.net open spaces event in Seattle :)
Nonetheless...
> I'm not sure we're on the same page with the term "story". Let's take a step
> back here.
in program code as a primary organizing construct for executable
specifications.
> The important thing is the automation of scenarios as acceptance tests.
> (Actually with outside-in development they start as an executable
> specification at the application level, and then become
> acceptance/regression/functional/user/whatever tests. See how the testing
> words still keep getting in the way, at the application level?)
tests are acceptance test and the term becomes quite irrelevant. I
observe different audiences for different profiles of tests, but they
all point to the acceptability of the software for a given segment of
the audience.
> - especially since it means that they are duplicates of the whole
>
> > team version of the artifact that lives outside of the code in order
> > to be accessible to, and changeable by the whole team.
>
> Not if you're doing it right. The story narrative probably lives on a wiki
> or in a document or on a spreadsheet on a file share or wherever the team,
> globally, thinks is the right place. There is probably an id, say a story
> number, that identifies the story.
I'm forced into it by dislocated teams, and if I can't find enough
cork boards and shoe boxes to hold the index cards. I do use wiki's
for details that are too big for an index card, but rarely so, and
typically when I can't get continuous customer availability and need
to queue story background and context for an iteration batch.
> The only thing the team cares about automating - at an application level -
> are the scenarios (several teams I work with still call them acceptance
> tests, but we have a shared understanding of what that means). This usually
> starts out as a paired activity between testers and devs, but over time the
> testers take more ownership of this.
>
> The scenarios are in two buckets, "in progress" and "completed". Any
> completed scenarios should always be passing, and should fail the build if
> they fail. The in-progress ones can fail.
level of an app, and to customer-facing tests. Am I reading this
right?
> Stories are
>
> > meant to be fluid - they are meant to be changed much more easily than
> > code.
>
> It's usually the understanding of the story that's variable, by which I mean
> the scope, by which I mean the set of scenarios that define "done" for this
> story. Code is the perfect representation for these.
story is in an iteration backlog - and then acceptance criteria might
change, and if so drastically, the card might represent an egregious
misunderstanding as surfaced by relatively massive in-iteration
changes to its specifications.
> When stories end up in code, they no longer take part in the
>
> > software production's visual control system,
>
> I don't know what you mean by "visual control system", but on the tens of
> projects I have seen using BDD the continuous build runs whenever anyone
> changes any code (which includes any configuration or environment details)
> and the results are published and available to the whole team, including
> external stakeholders.
is most suitable to part of a team. Story cards marching across an
iteration board as a higher-level visual control for the iteration
remains my preference for that level of information and for breadth of
audience.
> and we inevitably end up
>
> > with two versions of the truth - one version that is part of the
> > visual control system for the whole of the production effort, and
> > another one that is more frequently influencing only programmers'
> > understandings of the truth.
>
> If this is a real effect you are seeing then I can only suggest you aren't
> using automated verification and continuous integration properly. I'm happy
> to talk about the variance you're seeing.
to improve my continuous integration practices. However, I've got
doubts that the issue I'm pointing to is a CI automation issue. I see
this as an information radiation issue for a level of interest and
breadth of audience that is better served by less programmer-centric
media.
> Code is a much *harder* artifact that user stories, and therefore is
>
> > the wrong medium for stories.
>
> Ward Cunningham uses the metaphor of clay when he describes test-driven
> code. It is malleable and easy to change providing you have a reliable and
> repeatable method of validating that it still does what it is supposed to.
> I want to be able to rewrite, expand, delete or move scenarios as I wish,
> and to be able to instantly(ish) validate my new understanding. Having a
> scenario decomposed into steps, where each step is either setting up,
> executing or verifying my application, is a very powerful model for doing
> this. I've also observed a number of projects where just the shift in
> vocabulary (to given/when/then), without any of the automation, made a huge
> impact on the quality of dialog between stakeholders, analysts, testers and
> developers on software teams.
specification? I will personally become much more amenable to the
given/when/then grammar is a natural dialect of the humans on the
whole team rather than just the programmers.
> > Having multiple versions of softer
> > artifacts that are independently changeable will lead to multiple
> > versions of the truth
>
> Absolutely.
>
> - and in the case of stories in code - secondary
> > versions of the the truth that influence an entire, consistent
> > subsection of the whole team.
>
> Only if the stories-in-code are the secondary artifacts. In my world they
> aren't.
captured in code is a thing that a programmer does looking through a
programmers perspective out onto the world. It's such a clear lens
for the programmer that he isn't even conscious of its existence.
The natural extension of putting stories in code is the story exporter
that we then use to generate story text to print out and put on an
iteration board. You'll have to go a very long way to convince me
that this isn't more programmer predisposition to technology
fetishism. Time and dialog may change my mind, but in the mean time I
remain rather attached to my low-fi perspective on software production
and necessary means of technology-supported communication and flow
control.
> > User stories in code: only programmers can be so narrow-sighted about
> > software development. :)
>
> Hang on, there are two different audiences here at different levels of
> granularity, namely programmers and stakeholders. (This also refers back to
> the "why do we need a scenario runner" thread.)
>
> Programmers want examples. I've started calling TDD "coding-by-example", a
> framework like rspec programmers can write:
>
> describe CustomerRepository
> it should find a unique customer by id
> it should fail if it finds duplicate customers
> it should find customers by partial surname
>
> It's at the same level as an xunit test, and it's just as useless for a
> business stakeholder.
Then this is a test that a customer shouldn't see - unless he were an
>
> describe CustomerRepository
> it should find a unique customer by id
> it should fail if it finds duplicate customers
> it should find customers by partial surname
>
> It's at the same level as an xunit test, and it's just as useless for a
> business stakeholder.
extremely technical customer, at which point, we'd need some other
filtering.
> The stakeholders want to read stuff in their own language. They want to read
> scenarios, particularly edge cases, and tell you whether it's worth dealing
> with that edge case. (As a developer I can keep coding forever delivering
> ever-diminishing returns. But it's not my money.)
natural and more English-natural than the run-on expressions I see
coming out of the given/when/then API's. Here again, you'll have to
go a long way to convince me that this is a more expressive way to
create natural specification. I find this grammar very amenable to
encoding via programmatic API, but I find it unnatural as a simple and
natural language use.
I prefer the plain old English sentences that RSpec provides as a way
to capture expression. I much prefer this over breaking up cohesive
expressiveness over multiple API calls seemingly for the purposes of
fitting natural expressiveness to a programmer's interface.
I haven't seen anything yet that I can specify with an xBehave
framework that I can't specify using an xSpec framework. With an
xSpec framework, I don't the contextually-generated documentation, but
if I'm doing outer example-driven development for primary and edge
case coverage I need to formulate the text of the specification
manually. I can live with that. I see the tradeoff as a positive one
as I see xBehave grammars to lead to sub-optimization by fragmenting
and obfuscating specification code across xBehave API calls.
> The scenario runner (not story runner - you don't run stories)
you could get them back in the stable, but the appearance of a Story
primitive as a central organizing concept in the frameworks doesn't
really help.
> The scenario runner (not story runner - you don't run stories) is our shared
> definition of done, and what's more, our shared understanding of progress.
> This story comprises these 6 scenarios. When they work we're done. If your
> stakeholder meant something else by that story - either more or less - then
> scenarios are the unit of currency you can use to discuss that.
>
> As you quite rightly said, you can express any scenario in just a regular
> example, or xunit test case. The reason I don't is that they are for a
> different audience - the stakeholder - and that it turns out the
> given/when/then steps are usually of a suitable granularity to be easily and
> frequently reused.
of what the customer expressed as criteria for a story. Again, and
with all due respect for your experience and your work on tools and
your leadership, I believe that given/when/then grammar is a more
awkward form of expression and I don't believe that it is endemic too
English customer communication.
The only reason that I can see that this grammar is penetrating
business-natural communications contexts in software development
projects is that programmers are pushing it into place.
> In fact I would go further and say that all the scenarios for a story
> typically have the same core behaviour (the "when"), but with different
> givens resulting in a different outcomes. The testers very quickly become
> adept in describing the differences between scenarios. "This one is like the
> previous one but where the card is also reported stolen. In that case the
> ATM should retain the card."
grammar that makes it more natural or appropriate to that
communication. I could just have easily used some more absolutely-
worded version of: "This one is like the previous one but where the
card is also reported stolen. In that case the ATM should retain the
card."
card."
> I really value your energy in the BDD space. I hope I can help close the gap
> between our understandings of what BDD is and why it works.
I do, too. Although, I fear that we're going to run out of shared
> between our understandings of what BDD is and why it works.
understanding headroom in text media like email. I have a solid track
record of really ticking people off in text, but only mildly ticking
them off on the phone. In person, I'd simply win you over to my world
view through the magic of bar napkin scribblings and impassioned
dialog over a pint or two :)
Best,
Scott
Jimmy Bogard
Mar 24, 2008, 6:05:28 PM3/24/08
to behaviordriv...@googlegroups.com
> In person, I'd simply win you over to my world
> view through the magic of bar napkin scribblings and impassioned
> dialog over a pint or two
Just keep a close eye on that pint, you never know what might be put in it when you turn away.> view through the magic of bar napkin scribblings and impassioned
> dialog over a pint or two
For comparison's sake, the last project I came off of was a 4 week, 4 iteration project where we delivered 60-70 user stories. Unless we didn't size them like others do, any electronic medium would have been nigh impossible to keep track of all of these.
If you have a true co-located team, where both developers, managers and business stakeholders are together, what's the value added of any electronic system? My (admittedly limited) experience of persisting stories in anything but a card constantly muddled the conversation and drove it toward filling out the blanks in the tool. It seems like we should focus on the card and conversation as our default medium, and only push out to a tool when external compliance/requirements ask.
In most cases, folks looking for compliance just need a check box filled, so we might dump the finished user stories in a spreadsheet at the end of the iteration, but no one on the team ever uses Excel as the "System of record". Cards on the wall do that for us.
- Jimmy
Joe Ocampo
Mar 24, 2008, 7:06:41 PM3/24/08
to behaviordriv...@googlegroups.com
I agree completely! Electronic mediums of any type of tracking tools should always be approached with caution. Smaller team are hindered more by this approach more than anything else. BUT there is a need for electronic APM tools such as Ralley Dev etc. Within the enterprise space these tools are gaining tremendous traction. The jury is still out but my point is that if you are going to have to track your story progression and test acceptance branching you might as well leverage as many automated tools as possible to add value to the exercise.--
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
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
Scott Bellware
Mar 25, 2008, 1:11:23 AM3/25/08
to Behaviour Driven Development
Joe,
> Electronic mediums of any type of tracking tools should
> always be approached with caution. Smaller team are hindered more by this
> approach more than anything else. BUT there is a need for electronic APM
> tools such as Ralley Dev etc.
I don't think I see how you're discerning electronic story tracking
and Rally. Could you but a bit more context around how you see these
as different?
Thanks,
Scott
> Electronic mediums of any type of tracking tools should
> always be approached with caution. Smaller team are hindered more by this
> approach more than anything else. BUT there is a need for electronic APM
> tools such as Ralley Dev etc.
and Rally. Could you but a bit more context around how you see these
as different?
Thanks,
Scott
Jim
Mar 25, 2008, 9:21:48 AM3/25/08
to Behaviour Driven Development
Well I'm the Tester on the project in question so perhaps my
perspective might be of some interest.
I'm going to leave the theological arguments to other people and
concentrate on what I find interesting.
I'm interested in not having to manually retest the same things on
every build so I want automated tests.
I'm interested in having automated tests that run at as high a level
as possible. Ie driving the browser
I want tests that are well structured and have a recognisable pattern.
I want test results that are easy to read.
I want tests that are easy to write.
I want the tests to run every time we do a build.
I want the tests to test the stuff the customer is actually interested
in.
So...
So Watin allows us to test through the browser. This is good.
Nunit provides all the basic assertion stuff. Good too.
NBehave provides
1) A traditional test specification structure : Pre condition, action,
post condition
This keeps tests consistent and helps us understand exactly what it is
that is being tested in each test.
This all means that when a test fails it's obvious which bit of the
app is wrong what it did and what it should have done.
2) A clear mapping between a test and a story. This is good because it
is immediately apparent which bit of the system we are trying to
verify. We know that if a story has a requirement and it isn't in this
file then it doesn't get tested in the test suite at all.
3) Test output that is nice and friendly. This just makes it nicer to
read through and allows you to know what went wrong more easily.
Perhaps this is simply a matter of preference but I like it.
I'm not sure what the whole 'fluid story' subsection of the discussion
is about.
Sometimes a requirement changes after the code is done. When it does
you need to change the code and the tests to reflect this new
behavior. How could it be otherwise?
What do you mean when you say the story should be more fluid than the
code?
Surely any change in a story should be reflected in the code otherwise
what was the purpose of changing the story? In my mind there is a one
to one mapping between a story change and the code and the tests. If a
card is changed but is not being played till later then the current
tests are fine until the change is played at which point you need to
update the tests.
We want the tests to represent what we think the software does _right
now_. If we decide to change the code we have to change the tests.
It seems to me that NBehave is useful. Are you saying that however
good xbehave is other things have more value? If this is the case can
you give me an example using another framework which you think is more
effective and explain what the advantages are?
I find our current approach to be a good one but would be delighted to
find something even better.
James
perspective might be of some interest.
I'm going to leave the theological arguments to other people and
concentrate on what I find interesting.
I'm interested in not having to manually retest the same things on
every build so I want automated tests.
I'm interested in having automated tests that run at as high a level
as possible. Ie driving the browser
I want tests that are well structured and have a recognisable pattern.
I want test results that are easy to read.
I want tests that are easy to write.
I want the tests to run every time we do a build.
I want the tests to test the stuff the customer is actually interested
in.
So...
So Watin allows us to test through the browser. This is good.
Nunit provides all the basic assertion stuff. Good too.
NBehave provides
1) A traditional test specification structure : Pre condition, action,
post condition
This keeps tests consistent and helps us understand exactly what it is
that is being tested in each test.
This all means that when a test fails it's obvious which bit of the
app is wrong what it did and what it should have done.
2) A clear mapping between a test and a story. This is good because it
is immediately apparent which bit of the system we are trying to
verify. We know that if a story has a requirement and it isn't in this
file then it doesn't get tested in the test suite at all.
3) Test output that is nice and friendly. This just makes it nicer to
read through and allows you to know what went wrong more easily.
Perhaps this is simply a matter of preference but I like it.
I'm not sure what the whole 'fluid story' subsection of the discussion
is about.
Sometimes a requirement changes after the code is done. When it does
you need to change the code and the tests to reflect this new
behavior. How could it be otherwise?
What do you mean when you say the story should be more fluid than the
code?
Surely any change in a story should be reflected in the code otherwise
what was the purpose of changing the story? In my mind there is a one
to one mapping between a story change and the code and the tests. If a
card is changed but is not being played till later then the current
tests are fine until the change is played at which point you need to
update the tests.
We want the tests to represent what we think the software does _right
now_. If we decide to change the code we have to change the tests.
It seems to me that NBehave is useful. Are you saying that however
good xbehave is other things have more value? If this is the case can
you give me an example using another framework which you think is more
effective and explain what the advantages are?
I find our current approach to be a good one but would be delighted to
find something even better.
James
Scott Bellware
Mar 25, 2008, 2:37:20 PM3/25/08
to Behaviour Driven Development
James,
> So Watin allows us to test through the browser. This is good.
> Nunit provides all the basic assertion stuff. Good too.
> NBehave provides
>
> 1) A traditional test specification structure : Pre condition, action,
> post condition
> This keeps tests consistent and helps us understand exactly what it is
> that is being tested in each test.
> This all means that when a test fails it's obvious which bit of the
> app is wrong what it did and what it should have done.
>
> 2) A clear mapping between a test and a story. This is good because it
> is immediately apparent which bit of the system we are trying to
> verify. We know that if a story has a requirement and it isn't in this
> file then it doesn't get tested in the test suite at all.
>
> 3) Test output that is nice and friendly. This just makes it nicer to
> read through and allows you to know what went wrong more easily.
> Perhaps this is simply a matter of preference but I like it.
None of these things are exclusively provided by an xBehave framework
- and to me, it's arguable whether xBehave frameworks do a better job
of these things than the alternatives.
> I'm not sure what the whole 'fluid story' subsection of the discussion
> is about.
>
> Sometimes a requirement changes after the code is done. When it does
> you need to change the code and the tests to reflect this new
> behavior. How could it be otherwise?
Stories can change much easier than code - and they are allowed to.
We post them on physical cork boards and project principals can make
changes to them as required with little more than a pencil and
eraser. As fast and as fluid as thought and emerging understanding
can carry us.
It's understood that when a story is in-development, that it will not
change. If it does need to change - and that can happen - it may
seriously impact the expectations for the in-process iteration, and
such a change requires care and oversight.
If a requirement changes after a story is done ad accepted, then it's
dealt with using another story card marching through the process
again. A story doesn't change - it either remains or it is replaced.
If new criteria are needed for that story in a subsequent iteration,
then the story is re-introduced with the new criteria. It's the
criteria and the team's accountability to it that point the way to
initial task breakdown and tactical work scheduling, not the story
text.
> What do you mean when you say the story should be more fluid than the
> code?
Stories are easier to change than code. And they are more frequently
changeable and changed by people other than coders. Code is a harder
artifact than pencil and paper as it requires more steps for a non-
coder to change a story if the story's master copy is captured in
code.
Stories in pencil and paper, and the prominent display of story cards
in the vicinity of the people who own stories and change them, make
them easier to change.
> Surely any change in a story should be reflected in the code otherwise
> what was the purpose of changing the story?
I might change a story's role or the story's motivation and have no
impact whatsoever on the existing code. Stories are for capturing
knowledge for the whole team, including the user representatives who
originate the stories. They're not just entry points for code
generation.
> In my mind there is a one
> to one mapping between a story change and the code and the tests.
Again, only if there is a change to behavior. A story can change to
capture newer, clearer, and emerging in-process understanding and that
change may not impact the behavioral specification.
> It seems to me that NBehave is useful. Are you saying that however
> good xbehave is other things have more value?
Yes.
> If this is the case can
> you give me an example using another framework which you think is more
> effective and explain what the advantages are?
Any framework that allows you to express behavioral specifications in
the most human-natural way possible without jumping through a bunch of
API hoops to get there. I can use an xUnit framework or RSpec to
express behavioral specifications just as well as I can use an xBehave
framework to do the same.
xBehave-based code is more dense and more opaque than code that
doesn't interrupt the meaning of behavioral specification and
description code with so many framework API calls.
In the small, it's of little concern. In the large, over an entire
project, I see the resulting code it as a global suboptimization, and
my own process for continuous improvement has all but eliminated it as
a candidate framework in my work.
> I find our current approach to be a good one but would be delighted to
> find something even better.
When I look at my essential goals for engaging in BDD, and from the
perspective of those goals - namely, clear, direct, unfettered
communication and description of behaviors, and the organization of
these descriptions - I opt for whatever allows me to express those
things as best as possible.
I have observed that I get better results from tools that are more low-
fi than xBehave frameworks. That's probably counter-intuitive to
anyone who writes code, but I expect that. Coders often have
predispositions to ever more elaborate means. I know this because
I've taken time to make a study of it. I found it in myself as well
as in others. I believe, for myself, based on my observations of
myself, team mates, and other teams, that I am better served by
tooling other than xBehave. I also believe strongly that much of the
attraction to xBehave is driven by programmer predisposition to
elaborate technical means.
I am focused on expression and communication - both in code and in
specification documentation generated from code. I won't sacrifice
what I see as cleaner grammars and cleaner and more scannable
communications means for any tooling no matter how much merit the
tool's own implementation has.
For me, better is more "soluble". I'm not getting that from xBehave -
at least not in the large, and that's what counts for me.
Your millage - of course - will vary, especially depending on the set
of factors taken into consideration. I may change my factors next
year and end up back at xBehave :)
Best,
Scott
> So Watin allows us to test through the browser. This is good.
> Nunit provides all the basic assertion stuff. Good too.
> NBehave provides
>
> 1) A traditional test specification structure : Pre condition, action,
> post condition
> This keeps tests consistent and helps us understand exactly what it is
> that is being tested in each test.
> This all means that when a test fails it's obvious which bit of the
> app is wrong what it did and what it should have done.
>
> 2) A clear mapping between a test and a story. This is good because it
> is immediately apparent which bit of the system we are trying to
> verify. We know that if a story has a requirement and it isn't in this
> file then it doesn't get tested in the test suite at all.
>
> 3) Test output that is nice and friendly. This just makes it nicer to
> read through and allows you to know what went wrong more easily.
> Perhaps this is simply a matter of preference but I like it.
- and to me, it's arguable whether xBehave frameworks do a better job
of these things than the alternatives.
> I'm not sure what the whole 'fluid story' subsection of the discussion
> is about.
>
> Sometimes a requirement changes after the code is done. When it does
> you need to change the code and the tests to reflect this new
> behavior. How could it be otherwise?
We post them on physical cork boards and project principals can make
changes to them as required with little more than a pencil and
eraser. As fast and as fluid as thought and emerging understanding
can carry us.
It's understood that when a story is in-development, that it will not
change. If it does need to change - and that can happen - it may
seriously impact the expectations for the in-process iteration, and
such a change requires care and oversight.
If a requirement changes after a story is done ad accepted, then it's
dealt with using another story card marching through the process
again. A story doesn't change - it either remains or it is replaced.
If new criteria are needed for that story in a subsequent iteration,
then the story is re-introduced with the new criteria. It's the
criteria and the team's accountability to it that point the way to
initial task breakdown and tactical work scheduling, not the story
text.
> What do you mean when you say the story should be more fluid than the
> code?
changeable and changed by people other than coders. Code is a harder
artifact than pencil and paper as it requires more steps for a non-
coder to change a story if the story's master copy is captured in
code.
Stories in pencil and paper, and the prominent display of story cards
in the vicinity of the people who own stories and change them, make
them easier to change.
> Surely any change in a story should be reflected in the code otherwise
> what was the purpose of changing the story?
impact whatsoever on the existing code. Stories are for capturing
knowledge for the whole team, including the user representatives who
originate the stories. They're not just entry points for code
generation.
> In my mind there is a one
> to one mapping between a story change and the code and the tests.
capture newer, clearer, and emerging in-process understanding and that
change may not impact the behavioral specification.
> It seems to me that NBehave is useful. Are you saying that however
> good xbehave is other things have more value?
> If this is the case can
> you give me an example using another framework which you think is more
> effective and explain what the advantages are?
the most human-natural way possible without jumping through a bunch of
API hoops to get there. I can use an xUnit framework or RSpec to
express behavioral specifications just as well as I can use an xBehave
framework to do the same.
xBehave-based code is more dense and more opaque than code that
doesn't interrupt the meaning of behavioral specification and
description code with so many framework API calls.
In the small, it's of little concern. In the large, over an entire
project, I see the resulting code it as a global suboptimization, and
my own process for continuous improvement has all but eliminated it as
a candidate framework in my work.
> I find our current approach to be a good one but would be delighted to
> find something even better.
perspective of those goals - namely, clear, direct, unfettered
communication and description of behaviors, and the organization of
these descriptions - I opt for whatever allows me to express those
things as best as possible.
I have observed that I get better results from tools that are more low-
fi than xBehave frameworks. That's probably counter-intuitive to
anyone who writes code, but I expect that. Coders often have
predispositions to ever more elaborate means. I know this because
I've taken time to make a study of it. I found it in myself as well
as in others. I believe, for myself, based on my observations of
myself, team mates, and other teams, that I am better served by
tooling other than xBehave. I also believe strongly that much of the
attraction to xBehave is driven by programmer predisposition to
elaborate technical means.
I am focused on expression and communication - both in code and in
specification documentation generated from code. I won't sacrifice
what I see as cleaner grammars and cleaner and more scannable
communications means for any tooling no matter how much merit the
tool's own implementation has.
For me, better is more "soluble". I'm not getting that from xBehave -
at least not in the large, and that's what counts for me.
Your millage - of course - will vary, especially depending on the set
of factors taken into consideration. I may change my factors next
year and end up back at xBehave :)
Best,
Scott
heyn...@gmail.com
Mar 28, 2008, 5:09:34 PM3/28/08
to Behaviour Driven Development
Just to complement James' comment.
The one thing that is easy to change and to keep up-to-date is our
Acceptance Tests. They are so maleable and simple and understandable.
It's so easy to change them that it's annoying (we get to do more
refactor than I wish for :)).
Anyway, just to comment on that,
Bernardo Heynemann
> Scott- Hide quoted text -
The one thing that is easy to change and to keep up-to-date is our
Acceptance Tests. They are so maleable and simple and understandable.
It's so easy to change them that it's annoying (we get to do more
refactor than I wish for :)).
Anyway, just to comment on that,
Bernardo Heynemann
Colin Jack
Mar 30, 2008, 3:04:12 PM3/30/08
to Behaviour Driven Development
> The one thing that is easy to change and to keep up-to-date is our
> Acceptance Tests. They are so maleable and simple and understandable.
> It's so easy to change them that it's annoying (we get to do more
> refactor than I wish for :)).
Just to check I understand, do you mean because the tests are at a
> Acceptance Tests. They are so maleable and simple and understandable.
> It's so easy to change them that it's annoying (we get to do more
> refactor than I wish for :)).
high enough level, and thus aren't tied to implementation so that you
can refactor without having to change the tests.
Scott Bellware
Mar 31, 2008, 5:46:28 AM3/31/08
to Behaviour Driven Development
language remains applicable if the implementation needs to change. To
me, this means writing tests that describe the experience of the unit;
just like a high-level test might describe the experience of the user
interface, or an integration test can describe an execution path.
-Scott
Colin Jack
Mar 31, 2008, 4:54:14 PM3/31/08
to Behaviour Driven Development
> I try to make my unit tests read like high level tests so that the
> language remains applicable if the implementation needs to change.
Not sure how this works in practice, could you give an example?
> language remains applicable if the implementation needs to change.
Surely your most granular BDD specifications would need significant
rework if there was any serious refactoring though?
Scott Bellware
Apr 1, 2008, 2:09:47 AM4/1/08
to Behaviour Driven Development
Colin,
> Not sure how this works in practice, could you give an example?
If you gave me an example to work with, I might be able to.
Ultimately, I avoid the mention of names of implementation details in
spec names, and focus instead on describing low-level implementation
details from some universal experience (use case) that causes their
existence.
> Surely your most granular BDD specifications would need significant
> rework if there was any serious refactoring though?
Refactoring changes internals, so the perspective of the spec language
should be relatively unaffected.
-Scott
> Not sure how this works in practice, could you give an example?
Ultimately, I avoid the mention of names of implementation details in
spec names, and focus instead on describing low-level implementation
details from some universal experience (use case) that causes their
existence.
> Surely your most granular BDD specifications would need significant
> rework if there was any serious refactoring though?
should be relatively unaffected.
-Scott
Colin Jack
Apr 1, 2008, 2:58:58 AM4/1/08
to Behaviour Driven Development
> Refactoring changes internals, so the perspective of the spec language
> should be relatively unaffected.
Depends on what you describe as an internal and on what level your
> should be relatively unaffected.
testing at. I can definitely make changes that have no effect on
observable behavior (no client of public API can see change) but still
force me to redesign some test fixtures.
Scott Bellware
Apr 2, 2008, 2:45:24 AM4/2/08
to Behaviour Driven Development
Colin,
> I can definitely make changes that have no effect on
> observable behavior (no client of public API can see change) but still
> force me to redesign some test fixtures.
Possibly; depending on the change being made. But I'm speaking
specifically to the spec **language**. The descriptions of
observations being made will be relatively unaffected if the spec
language describes observations of the behaviors rather than the
implementations of the behaviors.
My focus is on the language that surfaces from writing specs that
describe experiences of the software, not it's implementation. If the
underlying behaviors change, and those changes cause changes to the
observations that can be made, we may no longer be strictly speaking
of **refactoring**. We may very well be in the domain of
**redesign**.
-Scott
> I can definitely make changes that have no effect on
> observable behavior (no client of public API can see change) but still
> force me to redesign some test fixtures.
specifically to the spec **language**. The descriptions of
observations being made will be relatively unaffected if the spec
language describes observations of the behaviors rather than the
implementations of the behaviors.
My focus is on the language that surfaces from writing specs that
describe experiences of the software, not it's implementation. If the
underlying behaviors change, and those changes cause changes to the
observations that can be made, we may no longer be strictly speaking
of **refactoring**. We may very well be in the domain of
**redesign**.
-Scott
Colin Jack
Apr 2, 2008, 2:52:59 PM4/2/08
to Behaviour Driven Development
Agree with all you say, but then I'd argue thats perhaps not Bernardo
meant when he discussed his tests making it much easy to refactor.
So far, just from my own experience, I'm not sure that writing specs
that focus on behavior rather than implementation is going to save me
much time when I refactor. For example if I do move a responsibility
from one class to another then the associated specifications probably
need to move to another fixture and the context/specification code
will also need to change. I'm not sure its thus all that different
from what I would have done with unit testing.
Not to say I think writing specifications with the behavior in mind
isn't key, just not convinced that what you describe solves the same
problem as high level acceptance testing from stories.
meant when he discussed his tests making it much easy to refactor.
So far, just from my own experience, I'm not sure that writing specs
that focus on behavior rather than implementation is going to save me
much time when I refactor. For example if I do move a responsibility
from one class to another then the associated specifications probably
need to move to another fixture and the context/specification code
will also need to change. I'm not sure its thus all that different
from what I would have done with unit testing.
Not to say I think writing specifications with the behavior in mind
isn't key, just not convinced that what you describe solves the same
problem as high level acceptance testing from stories.
Scott Bellware
Apr 4, 2008, 2:14:47 AM4/4/08
to Behaviour Driven Development
Colin,
> For example if I do move a responsibility
> from one class to another then the associated specifications probably
> need to move to another fixture and the context/specification code
> will also need to change.
That's possibly true only for specifications that are organized around
classes.
> I'm not sure its thus all that different
> from what I would have done with unit testing.
If you're used to having test fixtures apply to classes in your
system, then you won't see much of a difference.
> Not to say I think writing specifications with the behavior in mind
> isn't key, just not convinced that what you describe solves the same
> problem as high level acceptance testing from stories.
Depends on which organizational paradigm you're immersed in while
making the observation.
Best,
Scott
> For example if I do move a responsibility
> from one class to another then the associated specifications probably
> need to move to another fixture and the context/specification code
> will also need to change.
classes.
> I'm not sure its thus all that different
> from what I would have done with unit testing.
system, then you won't see much of a difference.
> Not to say I think writing specifications with the behavior in mind
> isn't key, just not convinced that what you describe solves the same
> problem as high level acceptance testing from stories.
making the observation.
Best,
Scott
Colin Jack
Apr 26, 2008, 8:33:16 PM4/26/08
to Behaviour Driven Development
> That's possibly true only for specifications that are organized around
> classes.
What I'm saying is that when you do refactor/redesign the
> classes.
impementation will need to change for the more detailed
specifications. So whilst names of the class/specifications may
survive you'll need to modify the implementation (or dump the
specifications and write new ones). This is not necessarily true for
acceptance tests (and here I mean acceptance test in the traditional
sense, black box system tests) so that's why I still think its valid
to say that the acceptance tests make it easier to refactor/redesign
safely (whether you write those tests as given/when/then or context/
specification doesn't seem important to this side of the discussion
though).
Reply all
Reply to author
Forward
0 new messages