BDD Automation 1

The primary output of BDD 1 is a team that can do the most basic parts of Behavior-Driven Development – collaborate to identify scenarios and specify behaviors using the Gherkin syntax. As part of that program, teams are taught how to use these scenarios as manual tests.

A follow-on step is for the team to automate those scenarios as tests. In a .NET environment, this typically involves the use of a technology named SpecFlow. Java environments tend to use a similar tool named Cucumber. Collectively we refer to such tools as “BDD automation tools”.

This program takes the team through the process of learning how to use a BDD automation tool to bind their existing Gherkin scenarios as automated tests. This is orthogonal to exactly how those tests are run, for instance, whether they are run as unit tests or UI automation tests is out of scope.

Recommended Program

The best way to get your team automating their BDD scenarios is with a combination of live, expert-led training and coaching. We recommend our BDD Automation 1 program, which includes a 2-day course and 4 days of follow-up coaching so the expert can help your team apply this methodology to their real work.

Course

This 2-day course covers how to bind BDD scenarios (the output of the process taught in BDD 1) as automated tests using the appropriate BDD automation tool. Unlike many of our courses, it is highly technology-specific and focused on the use of that technology.

Topics covered include:

• BDD Automation Tool Concepts
  1. Feature files
  2. Step definitions
  3. Context objects
  4. Hooks (4 big ones)
  5. Scoping constraints
  6. Dependency injection
  7. Scenario templates
  8. Tables
  9. Big strings
  10. Object mapping
• Interacting with unit tests
  1. BDD automation tools as unit testing frameworks
  2. How to share code between BDD automation bindings and traditional unit test suites

The course is interspersed with plenty of examples and exercises to help cement the ideas and practices in the learner’s mind.

Coaching

Afterward, a recommended 4-day coaching package helps learners implement what they learned in their real code using a real PBIs to deliver real code the new way. This is delivered as two days of coaching in the same Sprint as when the training is done and another two days during the following Sprint.

During these sessions, the expert will help the teams implement bindings. The expectation will be that the engineers immediately start writing bindings for scenarios, rather than watching the coach work on them for a while. This is because, assuming they have been through TDD 1, the team is already comfortable with driving production from code.

The output of the coaching sessions will be a number of automated BDD scenarios and, possibly, some finished PBIs (if the PBIs are small enough).

If the team has not been through TDD 1, already, the sessions will focus entirely on backfilling testing for existing code, at least for the two days of coaching in the first Sprint.

If the team is fully comfortable with a BDD automation tool as a technology and with using it to bind BDD scenarios as tests, then the two days of coaching in the following Sprint can be used to deliver some work toward completing PBIs. While this will reduce the risk of a team that hasn’t been through TDD 1 treating BDD automation as a “test-after” practice, it cannot eliminate it fully.

Benefits

The scenarios produced by BDD 1 are already valuable assets. They help engineers write better code, teams have better conversations, and testers align their work with expectations.

This takes it to the next level. By automating the BDD scenarios your team is already generating, you increase your system’s test coverage and do so in way that you know is aligned with that system’s requirements.

Costs

There are a number of components to take into account when considering the cost of this program:

1. Impact on capacity
2. Time to proficiency
3. Risks
4. Time to results

Impact on Capacity

This will significantly impact capacity during training, immediately after, and in the following Sprint. The team will not be able to deliver anything during the 2-day course and is likely to deliver at 50% capacity during the four of days of coaching thereafter. Therefore, when planning costs, you should consider a 4-day loss of productivity directly related to the training & coaching activities.

Time to Proficiency

You can expect your team(s) to stay in the “practicing” phase of adoption for six to eight weeks.

Risks

Time to proficiency may create some additional capacity loss.

If the team has not taken TDD 1, the primary risk is that the team won’t stick with the transformation, or they might split the difference and write their BDD bindings after they write their production code. You may need to plan for extra oversight to ensure this does not happen.

Time to Results

For a large codebase with poor test-coverage, there’s a lot of technical debt in the form of missing tests. You might not immediately see the results of writing more tests early on, as there is so much code that remains untested.

Prerequisites

• Program: BDD 1

Enablers

• Program: TDD 1
  Without this, engineers will not necessarily be comfortable driving production code from tests They will have to get comfortable with that while learning how to use a BDD automation tool, which is more complex than just using NUnit or MsTest. In other words, there will be an impediment in the form of the team needing to learn and get comfortable with two things at the same time.