What techniques do you use to simplify BDD step definitions?

[sarahdeery]

Check out our latest article by @picimako , “Strategies to Simplify Your BDD Step Definitions,” and dive into some practical techniques for managing BDD more efficiently. BDD (Behaviour-Driven Development) frameworks like Cucumber and JBehave are common, but working with glue code and step definitions can sometimes be overwhelming. Tamás shares valuable insights on how to simplify these processes, making your automation smoother and more manageable.

What You’ll Learn:

Streamlining Glue Code: Discover Tamás’ tips for reducing boilerplate and duplicate code in your step definitions and glue code.

Understanding Glue Code Essentials: Learn what glue code is and how it connects Gherkin steps to executable code, helping your automation scripts be more cohesive.

Using Lambda Expressions & Code Folding: Find out how Java 8’s lambda expressions and custom IDE integrations can help clean up your BDD step definitions for improved readability.

Exploring Alternatives to BDD Frameworks: Consider when it might be beneficial to skip BDD frameworks entirely and use alternatives for your test cases.

After reading, share your thoughts:

• What techniques do you use to simplify BDD step definitions?
• Have you tried any of Tamás’ suggestions in your automation? If so, what worked best for you?

[ozdamar.volkan (Volkan Ozdamar)]

In My opinion people understand and use Gherkin wrong. BDD should focus behavior and our Gherkin should a way to document it.

@When("^user attempts to log in with (.*) username and (.*) password$"

This is not a behavior , it should be like

@When("^user log in with valid credentials")

Or we can focus roles

@When("^Admin user log in with valid credentials")

This are actual behaviors , our focus should test valid or invalid attempts or roles . We should think what our domain is want to test.

[testnsolve (Vivek Tripathi)]

@ozdamar.volkan you and author both are correct - the different approach debate is only valid for kinda stake holder you have whom you report.

@ozdamar.volkan your approach is good if you have completely non technical stakeholders but author is correct when stakeholders are bit of technical.

[ozdamar.volkan (Volkan Ozdamar)]

Agreed but want to add this also.If you don’t apply BDD practices , writing Gherkin is just create another layer and increases maintanance costs for automation framework.If your business layer don’t need to read/write your Gherkin i don’t prefer BDD. BDD should be applied as a team with all phases.

[testnsolve (Vivek Tripathi)]

Fantastic representation @ozdamar.volkan

By your tone, I can understand the powers you have deciding the kpi’s and eco system related to testing practices but unfortunately every where testers not get as much powers like you have - resulting satisfying stakeholders education level - that they understand only non technical bdd scenarios or moreover they are technically strong and understand the deep insights written by a test automation dev on abstract level.

[poliarush (Mykhailo Poliarush)]

I think the biggest issue it’s not about implementation.
The gherkin is a common language and should be agreed with all involved parties.
If it’s only about QA then it’s in wrong way.

I see following issues with step definitions:

• duplicated and ambiguity steps
• complex steps with unique usage just only in one scenario
• low-level steps focusing on implementation but not on business logic
• low re-usage and too unique definition
• too abstract step definition where you don’t the context where to use it

We use testomat.io which have centrilized BDD steps database support. It works really well to understand usage, similarity, renaming and merging steps, having autocompletion based on steps database, etc Soon it will be AI feature to help with duplication, merging and maintenance.