Choosing which flavour of BDD framework to use

Recently Alan released a blog post discussing when you shouldn’t use Cucumber for a project that you are working on. But which steps should you take if you have decided that you want to go ahead and implement a BDD framework into your project? There are many tools and languages for you to choose, but which one do you go with?

It’s tempting to simply jump in, choose a tool and start working on integrating it into your project. However, to be successful it’s worth taking some time to understand your context before making your choice.

Understanding your agile team

Whilst choosing an approach or tool, it’s easy to be biased by your own experiences and preferences, but it’s important to be aware of your team’s context to help you decide the right tooling. If you are practising a strong outside in development approach, then it’s highly likely that the majority of your team will also end up using the tooling you choose to implement, so your choice will likely affect your team.

It is important to select tooling that empowers your agile team to be successful, doesn’t slow them down as they familiarise themselves with the tooling or language, and enables them to adopt both the tooling and an outside in development approach.

So before you choose, gather some information about your team by asking questions such as:

• Who is going to be using the tooling? - Find out who is going to be affected by your choices. Once you have identified those people, you can find out more about their experiences.

• What languages are they comfortable using? - Whilst it might be sensible to use the same language your product is written in, sometimes a different language is more suitable (more on that later). Before making that decision, are your team members comfortable with other languages? What if you want to work with Java when your team is primarily trained in JavaScript.

• Do they have prior experience with certain tools? - If there is already experience with tools within the team, it’s worth capitalising on it. That information could help you decide whether a tool is more or less suited to your team’s context.

Understanding your product

When you are choosing your tool, you might want to ensure that it aligns closely with your product, or you might choose something that sits separately to your product. Choosing the wrong tool will create extra work and all sorts of headaches for your team, so understanding your product and how to integrate your tooling is important.

It’s easy to take for granted what you know about your product, so take a step back and ask:

• What technologies and languages are you using? - This might seem simple: if your product is based on a language such as JavaScript, then use a JavaScript flavour. However, some languages work better with automation than others. For example, JavaScript - being a non-blocking architecture - makes it harder to create step-by-step executions; so would that be the best approach? Do you have the skills in the team to work with those issues?

• How are you structuring your product code? - Will you store your tooling in the same repository as your product, or keep it separate? The options you have available might help you decide which flavour of tooling to choose.

• How is your pipeline organised? - How and where you compile your code, run your tests and finally package and deliver your code can affect your choice. For example, having the capability to run everything locally as opposed to running on a continuous integration server will determine whether you want to use a tool that is closely aligned with the product, or something deliberately separate.

Selecting and adopting the right BDD framework

Once you have taken the time to understand both your product and your agile team, you can bring that information together and make a decision on the tool that best meets the needs of your agile team. Based on what you have learned, try and identify opportunities you can take advantage of as well as tracking potential risks that might derail your implementation work.

Then, before diving in and fully adopting the selected tooling, try a spike and see how you get on, just working with a small subset of scenarios with a teammate (pairing will give you different perspectives). If the spike proves to be successful then begin to roll out the adoption, but still take time to track its progress with regular discussions and retrospectives. Switching tools doesn’t have to complicate things, so long as you recognise the need to do so and take action early on in the project.