Associated simple data structures

[Rich Henry]

Hi all,

Quick question about 'a priori' definitions and simple data structures being defined under BDD. Thanks in advance...

Please consider this oversimplified example:

---------------------------------------------------------------------------------

Feature: Moving an actor

    Scenario: Move an actor to a new position

        Given the actor has existing coordinates of (2,2)

        When the actor receives a request to move north 5 units.

        Then her new coordinates should be (2,7)

---------------------------------------------------------------------------------

Inherent in this scenario is the definition of a coordinate (in this case a 2-element tuple, apparently consisting of integers?) and the need to represent a request to move the actor, in this case north by 5 units.

Now I can just create a definition for my coordinate-type that makes it a "2-element, integer tuple", and i can define a "move message" that will indicate the need to transform the original coordinate to the new coordinate. But these things are just artifacts of my immediate needs.

Is this the norm? 

Is the implication that, if the behaviors are implemented+working, and the ad-hoc design decisions don't fly in the face of common sense, then we are doing as well as BDD can do? 

Or is there a process to flesh out such details that I should be using in tandem with normal BDD practices?

Thanks again,

- Rich

[Dan North]

Hi Rich,

With this example you seem to be starting in the middle, with a scenario. I’m assuming some work happened to get you to this point, so let’s look at that. You decided you want an application that has actors, and that those actors can occupy and move in space, and that that is significant in some way. So already we’re surfacing some domain terms (“actor”, “space”, “occupy”, “move”).

I would start by understanding the goal of this application. What’s it for? Who will use it? Who else will be affected by bringing it into existence? (Operations and support folks, security and compliance people, different types of user and administrator). What will be different for them (what can they do that they couldn’t do before, or what becomes easier) with this software? That allows me to a) identify the stakeholders and b) start to surface some of the assumptions, dependencies and priorities that will inform delivery.

So now we’ve decided we need to Move an Actor to a new Position (caps indicates the domain-specific terms we’ve converged on, for now). There are many ways of modelling a position. Remember, all models are wrong, some are useful :)  So we decide that Cartesian coordinates in two dimensions will do for now. We probably have a side-discussion about the cost of reversal of that decision. How expensive would it be to introduce a Z coordinate? What about a time-axis intrinsic to the coordinate? Shifting to polar coordinates? Changing the zero-origin? Of the ways we could model it, which best supports the way we want to move actors and encapsulates the concern so it doesn’t tie us in too heavily?

How will we implement moving? Will this be event-sourced, so there will be a MoveActor event? Will there be an ActorMover or will actors move themselves? It’s appropriate to discuss implementation options at this stage because the way we describe the behaviour in the scenarios will contain tacit assumptions about implementation anyway, so better to surface those now. The domain model will almost certainly evolve as our understanding evolves, so you should assume both the scenarios and the steps beneath them will change over time.

So to get back to your original question, you are asking “is it the norm” to have decided on how you define a position in space, or to define moving as a transform of that position (is it instantaneous? are there side-effects?) by the time you’re writing that example. I would say probably yes, but don’t underestimate what (should have) happened on the way to this point, and the artefacts and shared understanding that (should have) emerged by then.

Cheers,

Dan

--

Dan North

@tastapod

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Rich Henry]

Thanks for the thoughtful response, Dan.

I think you were actually close to answering what my real question was (even though it was poorly presented in my post). The example above was contrived.

What artifacts do folks normally use to capture the "scenario-extraneous" details that come out of discussions/meetings/etc, like the ones you describe in your response? If I'm developing a "living document" shared by me and my stakeholders, I'm assuming capturing those details would be useful, and that I would want to have them "at hand" for anyone who shows up late to the game. The answer of "you have to make something up" is acceptable.

Thanks again Dan,

- Rich Henry

--

Dan North

@tastapod

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

[Tom Janssens]

I don't use gherkin-BDD but my specs do look similar.

I tend to define DSL-like builders that allow me to specify my tests like this

var an_actor = new actor();

var he = an_actor;

var a_starting_position = new {x=2,y=2};

var a_direction = new {x=0,y=5};

var the_expected_position = a_starting_position+a_direction;

void Move_an_actor_in_a_direction() {

   given(an_actor).at(a_starting_position);

   when(he).moves_in(a_direction);

   then(he).should_be_at(the_expected_position);

}

Op dinsdag 15 juli 2014 15:51:02 UTC+2 schreef Rich Henry:

[Dan North]

On 15 Jul 2014, at 14:51, Rich Henry <rhen...@gmail.com> wrote:

Thanks for the thoughtful response, Dan.

You’re welcome :)

I think you were actually close to answering what my real question was (even though it was poorly presented in my post). The example above was contrived.

What artifacts do folks normally use to capture the "scenario-extraneous" details that come out of discussions/meetings/etc, like the ones you describe in your response? If I'm developing a "living document" shared by me and my stakeholders, I'm assuming capturing those details would be useful, and that I would want to have them "at hand" for anyone who shows up late to the game. The answer of "you have to make something up" is acceptable.

The default answer for lots of teams has been “put it on the wiki” but I’ve seen many environments where the wiki is where information goes to die, nothing more than a hipster version of SharePoint.

Other than the executable specification itself, I see several kinds of information that are useful to track:

Narrative

These are the conversations we had around various decisions we made. In particular it is useful to capture:

- what we considered when we made a decision (about architecture, about a particular aspect of the domain model, about monitoring, ...).

- what we dismissed. I can see in the code that we ended up doing X. I don’t know we also considered Y and Z but went with X because unicorns.

- who was involved, both within and outside of the team.

My preferred medium for this is a product blog. You have timestamped entries so you can see when various conversations happened and decisions were made (or deferred). People can comment, either at the time or much later. You can revisit decisions to see what we considered. One of the big benefits is that it reduces a lot of low grade repetition:

- “Why are we using Maven? We should be using hipstr* instead!”

- “Take a look at the blog entries tagged “build” and you can see the various discussions we had. If you think something has substantively changed, or you have something to add, let’s have the conversation again. In any case you’ll understand how we got to where we are.”

- *crickets*

You can spin up a new WordPress instance on a VM in a few minutes.

* There’s no such thing as hipstr. If there were it would probably be a build tool.

Standards

Over time, we start to settle on How We Do Things Round Here. Things like documentation style, code style and conventions, packaging and naming, error-handling, in fact anywhere that a) everyone has an opinion and b) it really doesn’t matter as long as we’re consistent. These I want on a wiki. The wiki has to have excellent search (good ranking, uses word variants) and someone needs to be tasked with curating it, like a librarian. Part of on-boarding a new person is showing them round this wiki.

Backlog

This is work we have committed to. I don’t care how the team stores this as long as it is visible to all the stakeholders. That means if people are non-local there needs to be either an electronic version or a daily photo of the board, emailed out or posted on the blog. (I really like this by the way. I haven’t used it myself but someone told me how they use these as a stop-motion replay of the sprint for their retrospectives. Shows some interesting  trends.) It also needs to be lightweight enough that people aren’t intimidated by changing large swathes of it. I like Trello. Everyone seems to be using Jira, which astonishes me because it’s a (rather good) bug-tracker. Bonkers. For extra credit I also want to be able to get metrics out of it so I can measure e.g. lead and cycle times and WiP.

Ideas

People come up with ideas for the product all the time. Users, operators, administrators, developers, testers, anyone. You want a mechanism for capturing that that’s different from the backlog, otherwise people dump all their half-baked ideas into the backlog, which makes lead time metrics meaningless and creates an implied contract that you’ll eventually deliver their thing (which you will inevitably disappoint them with). I call this a wishlist. I wrote one recently with a client, that we called “Dear Santa”. Simple idea capture, with submitter’s name, description, benefit and timestamp. You should review the stuff in the ideas dump on a regular basis, and look for clusters or just simple good ideas to implement.

There are no doubt other categories of information, but if you can nail these you’ve made a good start.

Cheers,

Dan

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email tobehaviordriv...@googlegroups.com.

Visit this group athttp://groups.google.com/group/behaviordrivendevelopment.

For more options, visit https://groups.google.com/d/optout.

--

Dan North

Dan North & Associates Ltd

+44 7580 099876

d...@dannorth.net

http://dannorth.net

@tastapod

[Greg Young]

Crap now I have to create a tool called hipstr

--

Studying for the Turing test

[Adam Sroka]

All hail @wardcunningham for inventing hipster sharepoint before someone invented hipsters (or sharepoint) :-D

On Wednesday, July 16, 2014, Dan North <d...@dannorth.net> wrote:

[R H]

Thanks Dan, these are all great ideas. JIRA does project management too, and I think a few of its features would make great places to capture the kinds of details you're outlining here. We have a wiki but it does tend to be where stuff goes to die. The idea of controlling the backlog and not letting it become a dumping ground is a good tip -- I wasn't focused on that but I can see your point. Everyone needs a place to scribble.

I think a lot of this will come down to me having enough charisma to get people to do things the way i suggest. Im having trouble accepting the idea that some people may still prefer to overspecify/engineer/develop things into the ground -- it makes them feel safe. 

Perhaps i need a book on psychology instead of BDD.

You've been really helpful, thanks :)

[cliff v]

Hi Tom,

 

I like your builders.  Care to share a bit more of what they look like?

 

Thanks

 

cliff

--

Dan North

@tastapod

 

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

[Liz Keogh]

I've got something fairly similar here:

https://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs

(Please note that this is a really poor example of the level of detail needed for a scenario; nobody would ever talk like that. But it's a good example of builders, and works as an example of how to use an automation tool which is what it's really doing.)

Cheers,

Liz.

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Rich Henry]

I'll also chime in from the tooling/builder standpoint. Using the cucumber-scala DSL, when I have a feature including this scenario:

Scenario Outline: Add two numbers

Given The number <a>

And The other number <b>

When I add them

Then The result should be <c>

Examples:

|  a |  b |  c |

|  3 |  4 |  7 |

| -2 |  5 |  3 |

|  5 | -8 | -3 |

| -1 | -4 | -5 |

It generates the outline of this code, which I fill in the details. It uses regular expressions (as you can see) to get the arguments from the feature text:

class JunkDefinitions extends ScalaDsl with EN {

  var a: Int = 0

  var b: Int = 0

  var result: Int = 0

  

  Given("""^The number (-?\d+)$""") { (v: Int) =>

    a = v

  }

  Given("""^The other number (-?\d+)$""") { (v: Int) =>

    b = v

  }

  When("""^I add them$""") { () =>

    result = a + b

  }

  Then("""^The result should be (-?\d+)$""") { (expected: Int) =>

    assertThat(result, is(equalTo(expected)))

  }

}

The last line is using Hamcrest matchers (they are included in JUnit nowadays). You can also write your own custom matchers and Hamcrest gives you mechanisms to combine matchers with basic logical operators.

Anyway, just a quick look at some other tools to give you guys another data point.

- Rich

--

Dan North

@tastapod

 

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Tom Janssens]

Thanks Cliff,

What it mostly comes down to is that I try to describe "what" I'm doing in my tests, not "how" I'm doing it, which is exactly the reason why I use these builders that setup the test context and properly named variables.

I try to express my specs in the same way the business talks about them; they can use examples but in most cases they don't and just use the domain language...

For me personally Liz's example is not high-level enough, it so focuses on the how and not the what... But I do believe she states that in her post as well. (Typing on a cellphone ATM, so I can't check it.)

Regarding the gherkin language: I don't see a reason to add yet another "programming language" to write your specs, as you typically don't have the same tooling available for it. If you write a simple parser for the example I gave, replacing non-letters with spaces, you get a similar outcome without sacrificing any usability, flexibility and tooling...

For me personally the business should be able to read the specs, I experimented a lot with having clientsite specs using gherkin, but it was to much of a hassle for both me and my clients. YMMV

[Tom Janssens]

Clientsite=clients write

[cliff v]

Thanks for the reply, Tom.

I'm still curious to see what your given(), when() and then() functions look like. Are they returning some wrapper classes that provide the arrange/act/assert methods? Just interested in the guts of it all. Liz's example provided some insight into how one would structure it all.

I've been revisiting "Growing Object Oriented software" and trying to find some easier patterns to adopt for me and my team. I was looking into SpecFlow and other gherkin style frameworks and find them to be a bit much with the overhead even though I like what they communicate.

-----Original Message-----
From: behaviordriv...@googlegroups.com [mailto:behaviordriv...@googlegroups.com] On Behalf Of Tom Janssens

[cliff v]

Thanks Liz.  Very interesting code you have. 

[Tom Janssens]

Hey Cliff,

I couldn't find any examples in my boss work' however this is a similar approach but it doesn't use builders:https://github.com/ToJans/mauritius/blob/master/Example.Specs/ProjectSpecs.cs

I hope it provides you some value...

[Tom Janssens]

Boss=OSS
#DamnYouAutocorrect!

[cliff v]

Thanks, Tom, it does.

-----Original Message-----
From: behaviordriv...@googlegroups.com [mailto:behaviordriv...@googlegroups.com] On Behalf Of Tom Janssens
Sent: Tuesday, July 22, 2014 10:06 AM
To: behaviordriv...@googlegroups.com
Subject: RE: [BehaviourDrivenDevelopment] Associated simple data structures

[Rich Henry]

I must have had a different experience than you and Tom, because I found gherkin/cucumber to be minimalist and very easy to use. I admit it took me a few minutes to figure out how to plug in their runner, but after that it was smooth sailing. Very terse.

I'm trying to wrap my brain around testing my runtime code with test code that isn't tested -- like a set of ad hoc builders. Or do you guys write tests for these builders?

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

[George Dinwiddie]

Adam,

Hipster is older than you guess.
http://en.wikipedia.org/wiki/Hipster_%281940s_subculture%29

- George [always wanted to be a hep cat]

On 7/16/14, 7:32 AM, Adam Sroka wrote:
> All hail @wardcunningham for inventing hipster sharepoint before someone
> invented hipsters (or sharepoint) :-D
>
> On Wednesday, July 16, 2014, Dan North <d...@dannorth.net

> <mailto:d...@dannorth.net>> wrote:
>
>
> On 15 Jul 2014, at 14:51, Rich Henry <rhen...@gmail.com

> <javascript:_e(%7B%7D,'cvml','rhen...@gmail.com');>> wrote:
>
>> Thanks for the thoughtful response, Dan.
>
> You’re welcome :)
>
>> I think you were actually close to answering what my real question
>> was (even though it was poorly presented in my post). The example
>> above was contrived.
>>
>> What artifacts do folks normally use to capture the
>> "scenario-extraneous" details that come out of
>> discussions/meetings/etc, like the ones you describe in your
>> response? If I'm developing a "living document" shared by me and
>> my stakeholders, I'm assuming capturing those details would be
>> useful, and that I would want to have them "at hand" for anyone
>> who shows up late to the game. The answer of "you have to make
>> something up" is acceptable.
>
> The default answer for lots of teams has been “put it on the wiki”
> but I’ve seen many environments where the wiki is where information
> goes to die, nothing more than a hipster version of SharePoint.
>
> Other than the executable specification itself, I see several kinds
> of information that are useful to track:
>

> *Narrative*

>
> These are the conversations we had around various decisions we made.
> In particular it is useful to capture:
> - what we considered when we made a decision (about architecture,
> about a particular aspect of the domain model, about monitoring, ...).
> - what we dismissed. I can see in the code that we ended up doing X.
> I don’t know we also considered Y and Z but went with X because
> unicorns.
> - who was involved, both within and outside of the team.
>
> My preferred medium for this is a product blog. You have timestamped
> entries so you can see when various conversations happened and
> decisions were made (or deferred). People can comment, either at the
> time or much later. You can revisit decisions to see what we
> considered. One of the big benefits is that it reduces a lot of low
> grade repetition:
> - “Why are we using Maven? We should be using hipstr* instead!”
> - “Take a look at the blog entries tagged “build” and you can see
> the various discussions we had. If you think something has
> substantively changed, or you have something to add, let’s have the
> conversation again. In any case you’ll understand how we got to
> where we are.”
> - *crickets*
>
> You can spin up a new WordPress instance on a VM in a few minutes.
>
> * There’s no such thing as hipstr. If there were it would probably
> be a build tool.
>

> *Standards*

>
> Over time, we start to settle on How We Do Things Round Here. Things
> like documentation style, code style and conventions, packaging and
> naming, error-handling, in fact anywhere that a) everyone has an
> opinion and b) it really doesn’t matter as long as we’re consistent.
> These I want on a wiki. The wiki has to have excellent search (good
> ranking, uses word variants) and someone needs to be tasked with
> curating it, like a librarian. Part of on-boarding a new person is
> showing them round this wiki.
>

> *Backlog*

>
> This is work we have committed to. I don’t care how the team stores
> this as long as it is visible to all the stakeholders. That means if
> people are non-local there needs to be either an electronic version
> or a daily photo of the board, emailed out or posted on the blog. (I
> really like this by the way. I haven’t used it myself but someone
> told me how they use these as a stop-motion replay of the sprint for
> their retrospectives. Shows some interesting trends.) It also needs
> to be lightweight enough that people aren’t intimidated by changing
> large swathes of it. I like Trello. Everyone seems to be using Jira,
> which astonishes me because it’s a (rather good) bug-tracker.
> Bonkers. For extra credit I also want to be able to get metrics out
> of it so I can measure e.g. lead and cycle times and WiP.
>

> *Ideas*

>> <http://c2.com/cgi/wiki?AllModelsAreWrongSomeModelsAreUseful> :)

>> @tastapod <https://twitter.com/tastapod>

>>
>>
>>
>> On 14 Jul 2014, at 19:54, Rich Henry <rhen...@gmail.com

>> <http://gmail.com/>> wrote:
>>
>>> Hi all,
>>>
>>> Quick question about 'a priori' definitions and simple data
>>> structures being defined under BDD. Thanks in advance...
>>>
>>> Please consider this oversimplified example:
>>>

>>> ------------------------------__------------------------------__---------------------

>>> Feature: Moving an actor
>>>
>>> Scenario: Move an actor to a new position
>>> Given the actor has existing coordinates of (2,2)
>>> When the actor receives a request to move north 5 units.
>>> Then her new coordinates should be (2,7)

>>> ------------------------------__------------------------------__---------------------

>>>
>>> Inherent in this scenario is the definition of a coordinate
>>> (in this case a 2-element tuple, apparently consisting of
>>> integers?) and the need to represent a request to move the
>>> actor, in this case north by 5 units.
>>>
>>> Now I can just create a definition for my coordinate-type
>>> that makes it a "2-element, integer tuple", and i can define
>>> a "move message" that will indicate the need to transform the
>>> original coordinate to the new coordinate. But these things
>>> are just artifacts of my immediate needs.
>>>
>>>
>>> Is this the norm?
>>>
>>> Is the implication that, if the behaviors are
>>> implemented+working, and the ad-hoc design decisions don't
>>> fly in the face of common sense, then we are doing as well as
>>> BDD can do?
>>>
>>> Or is there a process to flesh out such details that I should
>>> be using in tandem with normal BDD practices?
>>>
>>> Thanks again,
>>>
>>> - Rich
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "Behaviour Driven Development" group.
>>> To unsubscribe from this group and stop receiving emails from
>>> it, send an email tobehaviordrivendevelopment+

>>> <javascript:_e(%7B%7D,'cvml','behaviordrivendevelopment%2Bunsu...@googlegroups.com');>__unsub...@googlegroups.com
>>> <javascript:_e(%7B%7D,'cvml','behaviordrivendevelopment%2Bunsu...@googlegroups.com');>.

>>> To post to this group, send email

>>> tobehaviordriv...@__googlegroups.com <http://googlegroups.com/>.
>>> Visit this group
>>> athttp://groups.google.com/__group/__behaviordrivendevelopment <http://groups.google.com/group/behaviordrivendevelopment>.
>>> For more options, visithttps://groups.google.com/d/__optout
>>> <https://groups.google.com/d/optout>.

>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Behaviour Driven Development" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email

>> tobehaviordrivendev...@googlegroups.com
>> <javascript:_e(%7B%7D,'cvml','behaviordrivendevelopment%2Bunsu...@googlegroups.com');>.

>> To post to this group, send email

>> tobehaviordri...@googlegroups.com
>> <javascript:_e(%7B%7D,'cvml','behaviordriv...@googlegroups.com');>.

>> Visit this group
>> athttp://groups.google.com/group/behaviordrivendevelopment.
>> For more options, visithttps://groups.google.com/d/optout.
>
> --
> Dan North

> *Dan North & Associates Ltd*
> +44 7580 099876
> d...@dannorth.net <javascript:_e(%7B%7D,'cvml','d...@dannorth.net');>
> http://dannorth.net
> @tastapod <https://twitter.com/tastapod>

>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to behaviordrivendeve...@googlegroups.com
> <mailto:behaviordrivendeve...@googlegroups.com>.

> To post to this group, send email to
> behaviordriv...@googlegroups.com

> <mailto:behaviordriv...@googlegroups.com>.

> Visit this group at
> http://groups.google.com/group/behaviordrivendevelopment.
> For more options, visit https://groups.google.com/d/optout.

--

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Adam Sroka]

I don't think it means the same thing anymore. Modern Hipsters spend more time on social media than listening to bebop. 

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.