Starting out with BDD

[Neil McLaughlin]

Hi All

We are just starting out on a greenfield project and are driving our
development from executable acceptance tests using an outside-in/BDD
approach (SpecFlow + nunit + htmlUnit). We were previously using
stories and TDD, but no executable scenarios, as a fairly agile team.

Although we have a long way to go things are going OK at the moment
and we feel it is bringing some real focus to the development process.
However a lot of the early stories are largely admin type CRUD - for
example functionaility to set up user defined entities and their user
defined properties within the system and to provide a mechanism for
relating these entities to each other.

I have read Gojkos excellent blog post on the anatomy of good
acceptance test (http://gojko.net/2010/06/16/anatomy-of-a-good-
acceptance-test/) after having attended the agile testing meeting on
which it is based. Although I thought I understood what makes a good
test where a business rule needs elaborating I am struggling with this
infrastructure stuff - this manifests itself in difficulty in coming
up with the "So that I can ..." bit of the story as the infrastructure
stuff is only there to support the meat of the application which is
capturing entity specific data to support the business.

A lot of the scenarios are of the form:

Given the system doesn't have something
When I create something (using the web interface)
Then visiting a listing page shows the thing I created

I keep in mind that the scenarios are there to facilitate
communication but they seem to state the obvious or do you need to
start with the simple stuff to tease out the edge cases. I am also
aware that some of the tests are tending towards scripts using the
driving the UI.

Does anyone have any advice about how to write tests for this sort of
stuff or any experiences in starting out with BDD they can share.

Thanks in advance

Neil

Cross posted to the specflow group

[Gojko Adzic]

Hi,

(my previous message got dropped half-way, so sorry if this ends up as
a double post)

CRUD is not a user story, it's a screen. It's not a business function,
but implementation detail. Why do the business users need a particular
CRUD screen? (I know it sounds as a stupid rhetorical question, but
I'm serious) What does it allow them to do?

Often you don't need to implement an entire CRUD screen and deliver
them one by one. Sometimes there is value in releasing two screens
that allow you to set a subset of properties but together they bring
value. You can then automate these tests through the UI and use the
CRUD screens, but that will be hidden in the automation layer. Say for
example that we have a risk report that lists users and their card
numbers:

Scenario: Only regular customers with a specific risk category and
card type show up in risk reports
Given the following users
|name| type| card type| card number| risk category|
|Mike |VIP | Mastercard |53111 11111 11111 1111|X|
|Tom |VIP| Visa |41111 11111 11111 1111|Y|
|John |Regular |Mastercard |51111 11111 11111 1111|X|
|Steve |Regular |Mastercard |52111 11111 11111 1111|Y|
Then the risk report for Mastercard and category X contains the
following data
|John | 51111 11111 11111 1111|

This could, for example, invoke the user CRUD to save a user name,
type and risk category and a completely different CRUD to save card
details for that user. Any other information that would go on that
CRUD (addresses, card expiry dates etc) aren't part of this story or
criteria because they are not important for this particular report.

Start with the outputs, the reports that the system produces, instead
of data entry operations. this ensures that you have the data you need
to produce the reports at the end, and that you don't have superfluous
data that nobody really cares about. if you don't do that, from my
experience, data schemas are often overcomplicated and contain many
things that simply aren't used at the end at all.

gojko

[Pankaj Nakhat]

Hi Neil,

Apart from what Gojko said, i think the part of the problem falls how stories are sliced.  I have often seen that stories are big features (Epic) and they are then broken in to slices (Tasks), and individual slice may not deliver business value in its own as it may be too low level or its not tangible.

As Gojko said "Start with the outputs, the reports that the system produces, instead

of data entry operations. this ensures that you have the data you need
to produce the reports at the end, and that you don't have superfluous

data that nobody really cares about", 

I have found this approach really usefiul in terms of slicing the stories too.

Regards,
Pankaj Nakhat
www.pankajnakhat.com/blog1
t : @pnakhat

[Nader Talai]

Neil

 

I would use outside in as Gojko says for defining what we need to do and ensure that scope matches what we need. 

 

When it comes to designing and writing the code use input to outputs i.e. follow the inputs to drive out what you do using tdd.  This means that your slices end up as thin ones and initially will have very little on the UI side but your code goes all the way through and you can start growing your design. 

 

You may need mocks to define what you need from external systems and stay focused on your objective and not the external system.

 

Nader

[Neil McLaughlin]

Thanks for the responses - they have been helpful.

Perhaps a complicating factor is that we are developing a generic
business intelligence tool
which is being driven by the requirements of 3 initial groups of
users. There are therefore
two types of customer; the owner of the tool and the owners of the
solutions implemented using the tool.

So the stories for the tool owner would be focused around the ability
to do generic things like authentication,
creating user defined entities & properties and their relationships
along with reporting on entity properties
across multiple entities, etc.

The stories for the owners of the implementations would be defined
using specific scenarios in terms of
outputs. I guess the concern we had initially was that these stories
seemed too big - there would be a large amout
of development effort (due to the amount of infrastructure work)
sitting under one story. I guess that part
of the problem is about combining the ideas of partitioning by
customer features and developer work
items which in reality are two separate things.

This large story (made up of concrete scenarios) seems a good starting
point but it is all about the 'outside' part
of 'outside-in'. I like the BDD idea described in the Ruby RSpec book
of working inwards using the same scenario
driven approach. Perhaps part of the problem is we focusing on end
users for all parts of our BDD whereas, as we
drive inwards, the behaviour we define is for consumers of our domain
objects (ie the system) rather than end users.

I think that part of our problem is one of partitioning our tests and
identifying who the user is.

Any thoughts?

[Nader Talai]

My suggestion is to focus on the specific uses of the tool and the
generalisation should follow (if required later).

I would look at the three specific users that you have who want to use your
product and find out how they want to use it and drive stories out from
them, ideally I would work with one of them implement show the working code
incorporate their feedback and then add/extend functionality.