Several Web development teams that use BDD (Behavior-Driven Development) have asked me how WalkHub relates to BDD. After some research I believe that there could be a lot of value in WalkHub’s ability to record and visualize user interaction scenarios for BDD teams. With it a team could:
- Save time & money when building a BDD test suite from scratch for an existing project.
- Educate customers about the existing features in an (open source) product, through a live experience to prevent “this is not how I imagined it” scope creep.
- Improve User Acceptance Testing, by visualizing the feature scenarios on top of a website. This is especially useful when a customer doesn’t want to systematically read the Gherkin/Cucumber specification.
Introduction
Behavior-driven development or BDD, is a development methodology that enables teams to test their software against business expectations, so that they can deliver “software that matters”. It combines the general techniques and principles of Test-Driven Development with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development. (adapted definition from Wikipedia).
WalkHub is an open source web application that enables teams and communities to collaboratively create a series of Walkthrough tutorials for web applications: step-by-step tutorials that describe an online interaction process with a sequence of text bubbles that appear on top of a website.
Already early on in the development of WalkHub there was a strong interest from people in the Drupal community that wanted to incorporate WalkHub into their BDD toolchain. With the launch of our crowdfunding campaign on Indiegogo, we are now getting a lot of requests for this feature set. This white paper explores how and why this could be done.
How it could work
Recording Gherkin/Cucumber
Now that WalkHub has a recorder, all you need to do to capture an interaction process on WalkHub, is to start the recorder; tell it where to start; and do the process you want to capture (a lot like making a screencast). The recorder captures the interactions with the site and turns them into a Walkthrough.
Every Walkthrough step on WalkHub currently has:
- an optional title
- a description field
- a step highlight
- 3 Selenium command fields
It would be fairly straightforward to make it possible to export Gherkin or Cucumber: We could add a “BDD scenario step” field and during the recording process automatically populate it with a best guess for the scenario description using a replacement pattern. For example this step
Could be automatically generated using a replacement pattern for the “type” command that looks like
So that it is automatically creates:
And I fill in “id=edit-submitted-name” with “Kristof”
These replacement patterns could be configurable so that you can switch the replacement patterns from one project to another.
Assertions (Then)
An "add a step" button in the player could allow you to also add assertion steps. At first those steps wouldn’t have to do anything in the Walkthrough, but could let you add a custom assertion. Later we could add some sort of UI for generating assertions.
Prerequisites (Given)
WalkHub already uses prerequisites to let you define preconditions you need to fulfil before you can successfully play a Walkthrough and the Walkthroughs that help you meet those preconditions. When exporting Gherkin we could export the titles of these Walkthroughs as a “given” in the scenario. If that prerequisite wasn’t yet available Behat will throw an “unknown step definition” error. You can then define it in your feature context.
Importing Gherkin/Cucumber scenarios
This is more difficult, because it’s a best practice to condense multiple steps into a single step definition where that makes it easier to read the scenario, it is possible that steps no longer translate to a single step in WalkHub. To some extent we could address this with the prerequisite system, but I think it would be the easiest if we would do a simple import as described as follows:
- Dump the whole test in the description (for reviewing purposes).
- Import the first step definition with "I am on" as the Walkthrough open command (that opens the page).
- Create steps for each scenario step.
- Add the description of the imported scenario step in the “BDD scenario step”.
In a first incarnation this could be a text field that lets you paste a Gherkin/Cucumber scenario that gets transformed into a Walkthrough.
Poor man’s BDD
In WalkHub you could use natural text to define step scenarios. These wouldn’t need to take into account any formal Gherkin/Cucumber language and after creation map the steps from a scenario onto the site using the in-place-editor in WalkHub. You can use the move feature to select the element to interact with and define the action the step needs to do. This could in turn be exported as valid Gherkin/Cucumber...
The in-place-editor makes it easy to move a step to another HTML element: just click the move button and click on the element where the step should be instead.
Why should you even consider using WalkHub for BDD?
Speeding up adoption of BDD on existing projects
Ideally a project works with a BDD workflow right from the start. In that case there shouldn’t be any functionality that needs to be documented after the fact. In reality however it often happens that teams decide to switch to BDD at a later time in a project cycle. In which case it can be very time consuming and tedious to create a complete feature suite.
WalkHub’s recorder enables users to capture a scenario that they do in their browser. This represents 3 important improvements when creating test suites (in bulk):
- A record then annotate process reduces the cognitive load for the test author.
- With the recorder anyone can create of tests, you don’t need technical knowledge to do so. A test author just needs to be able to do the process that needs to be tested.
- The recorder automatically captures the selectors the test needs, no need to go back and forward between Firebug and the text editor where you are creating the test.
Maximizing cost savings when extending (open source) products
When scoping a project that will build further on a pre-existing product, it is incredibly important that both the customer and analysts have a good knowledge of the implementation decisions that have been made in that product. When existing solutions are not taken into account during the design of a project, existing features in the product become liabilities instead of time savers when they need to be refactored or sometimes even removed and rebuilt.
A complete documentation of pre-existing features and their usage scenarios could be used to communicate the pre-existing feature set. Instead of defining scenarios from scratch analysts and customers could use these to perform a gap-analysis to find what scenarios need to be changed. This allows the development team to focus on those changes that generate the largest value, while getting explicit buy-in on all pre-existing features.
In the Drupal community, we call this the Drupal way. It is very hard to quantify the Drupal way and to ensure that customers and analysts know Drupal sufficiently to prevent them from re-inventing the wheel. I am sure other software products have similar issues. Educating the customer to a sufficient extent is often not possible. Even if Gherkin is a readable quasi-natural language, it is unrealistic to expect that a customer will be able to know the full extent of what they are buying into. User stories in text don’t solve this problem.
To prevent running into conflicts late in the development cycle, a team could provide a complete set of UI documentation with WalkHub that allows the customer to experience the stories in the interface, rather than in an abstracted format. This protects development teams from scope creep, and conflicts about features that worked “differently in the customer’s head”.
User acceptance testing with BDD scenarios
It’s one thing when your test suite doesn’t fail, it’s a whole other thing when the customer accepts the solution. With WalkHub you can send a customer a Walkthrough when you’ve finished building a feature. It’s possible to comment Walkthroughs, and we could enable commenting on individual Walkthrough steps.
Generating end-user documentation from scenarios
You can use Walkthroughs to explain how a feature works, automatically test if your documentation is still up-to-date, and to update the screenshots in your manuals. Adding the Walkthrough format with its screenshot widget as a deliverable for the BDD toolchain can help bridge the gap to end-users.
Should we make this happen?
At first when I was asked about BDD I was very sceptical, it sounded like a niche application of WalkHub that would require us to add a lot of features. But over 70% of the organizations I am currently discussing WalkHub with would like to use it in their BDD workflow. These are also the organizations that would consider contributing to the development of WalkHub. They have already bought into the importance of documentation and the “your specification is your test is your manual” concept.
What do you think, should we throw all our resources behind BDD to make WalkHub succeed or is this an expensive distraction?
If you think WalkHub could help you save money and/or time in your BDD process please fill in the following form. If we don’t get sufficient feedback we won’t pursue this avenue. So if you know someone or a community who might be interested in using WalkHub for BDD/Behat, please tell them about this survey.
