rapaul.com

Vertical Slicing

Vertical slicing is one of the key features I see in being able to deliver features rapidly, with the code developed being clean and simple to extend to future requirements. The basic premise is that instead of dividing work into horizontal slices where a task is something like create a database schema. You instead slice your work into small user stories where each story is something that can be demonstrated to a stakeholder on its own. These stories will often touch multiple ‘layers’ of the application such as the view layer, service layer and persistence layer.

The benefits of this approach are plenty,

• Each story delivers value, no matter how small.
• Work in progress (WIP) is reduced as tasks such as ‘create a schema’ are not left floating around until the tasks that utilise them are completed.
• You can focus your development effort on purely delivering just enough code to satisfy the story, without adding code you think you may need (YAGNI).
• Tight feedback loop.
• Reduced merge conflicts – your local code diverges from master for shorter spans.

Slicing stories vertically fits well with the Outside-In approach favoured by Behaviour Driven Development. Using an Outside-In approach you take a user story, build some acceptance criteria around it (potentially automated with a tool like Cucumber), then work from the outside in to complete the story. e.g In a web application I like to start with the view layer, building in enough of the view to satisfy the acceptance criteria. The view layer now defines the acceptance criteria for the layer beneath it, in this case the controller. This process continues with each layer creating a pull signal to write more code at a lower level. Development continues in a Test Driven style until the acceptance criteria for the story is met.

An example case I like to give for vertical slicing is for a search feature we implemented at f1000.com. I talk briefly about it in my talk on Acceptance Testing with Geb (39 minutes in). The search feature contains a number of different stories – developing the entire feature behind closed doors without a tight feedback loop would invariably result in building the wrong thing, even if it was what was originally asked for. Instead we took an iterative approach with thin vertical slices for each story.

The first cut of the search feature was designed to offer the greatest value, allowing users to search by keyword. The user could not go to the second page of results, change the sort order or any of the other features we ended up with. By getting a first cut out to our stakeholders early on they could immediately play with search and provide feedback on the direction. We continued in such a fashion adding support for more stories based on the importance, for example multi-domain search (evaluations, reports, faculty, blog) adds more value (and was done first) than being able to move to the next page in the results as the most relevant hits should appear on the first page.

Related reading:
http://www.energizedwork.com/weblog/2005/05/slicing-cake.html

Tags: bdd, cucumber, stories, verticalslicing, wip

Acceptance Testing with Geb

Below are the slides and video of a presentation I gave at SkillsMatter on Acceptance Testing with Geb. Fast forward to 1:30 when I start the presentation.

This talk will cover the basics of using Geb http://geb.codehaus.org to automate browser testing.
It will compare Geb with raw WebDriver/Selenium showing Geb’s expressive Groovy API.It will also demonstrate how to integrate Geb with acceptance testing frameworks, namely Cucumber via Cuke4Duke.

It also cover an experience report on how and why we transitioned from raw WebDriver to Geb and how existing WebDriver projects can be ported across to Geb with minimal initial effort due to its underlying use of WebDriver.

Tags: bdd, cucumber, cuke4duke, geb, groovy, selenium, slides, teamcity, webdriver