Behavior-Driven Development is a package development methodology that promises to resolve the common communication issues that we look between business and technical people. Here ’ s a snipping fromCucumber documentation:

& quot; Behavior-Driven Development (BDD) is a set of practices that aims to reduce some common uneconomical activeness in software development:

• Rework make by misunderstood or vague requirements

• Technical debt cause by reluctance to refactor code

• Slow feedback cycles caused by silos and hand-overs

BDD aims to narrow the communication gaps between team members, foster better understanding of the customer and promote continuous communication with real world examples. & quot;

Unfortunately, as is all too common in the tech industriousness, we spend a single hour learning about a topic, skip over all of the important documentation and testimonial, and turn the issue into a Frankenstein of our own making. As a result, we create concepts such as:

• Fragile (Waterfall Agile) —where we lead a few pieces that we like from the Agile manifesto and unite it with waterfall,

• Selenium WebDriver for API automation—where we take an automation tool and start using it to clear all automation problems,

• Custom implementations of page objects—where sooner than keep it simple, we create unneeded abstractions, and

• The opposite of BDD, BDD automation

As a Solutions Architect (SA) working for Sauce Labs, I get to see about a twelve client and plausibly a hundred automation engineers a year. Hence, I see a lot of different codification and implementation approaches. The one that systematically get the nearly problems is BDD examination automation. As a team of SAs, with a combined 100+ age of automation experience, we have seenone good effectuation of Cucumber automation from Aslak Hellesøy, the creator of Cucumber.

In my experience, the biggest problem with BDD automation is that almost cypher follows the principle and thought of BDD, as prescribed above. Instead, we but hear a buzzword, BDD, and if we build it, we hope that it will solve our challenges. BDD is an first-class idea. The problem is that we don ’ t follow what has been lay out by the creators.

Yet it ’ s funny because although technical challenges can surely embarrass automation, cultural problems will make full mechanisation unimaginable. “ BDD intention to specialize the communicating gaps between team members, foster better understanding of the customer and promote uninterrupted communication with real-world examples. ” (Cucumber.io)

I will never say it better than the Almighty of Cucumber himself:

& quot; If you think Cucumber is a examine tool, delight say on, because you are wrong.

There is a operation to follow that regard many roles on the package team.

This process is called BDD. It ’ s what came out of that camp I mentioned. BDD is not a tool you can download. & quot;

-- Aslak Hellesøy,The World ’ s most misunderstood collaboration tool, Cucumber.io

Let ’ s discuss the job that we open ourselves up to when we start trying to do BDD test automation.

1. BDD automation is be performed by the wrong team

Who is creating the actual BDD specification file in your organization? Is it the three amigos sitting down together, talking, collaborating and leave with a common words around the scheme requirements?

If that ’ s not the case, then that ’ s already going against BDD conventions.

However, in most organizations, the mechanization engineer is the one that is but converting manual tests into Gherkin scenarios. The product persona refuses to learn the proper Gherkin syntax for test mechanisation. Hence, the automation technologist is left to figure this out on their own.

Pro tip: Tools like SUSA can handle this autonomously — upload your app and get results without writing a single test script.

If we think about the genuine termBehavior- Driven Development, the doings of the system should motor the pattern of the system. Who on the team cognize the most about the behavior of the system?

1. Automation technologist

2. Manual tester

3. Business Analyst

4. Developer

You can pick any option except the automation engineer and they would all get more understanding about the systembehavior!

So, why is the person that is least certified actually writing the Behavior Driven automation scenarios?

Something isn ’ t rightfield here…

And that ’ s the whole job. It ’ s not that BDD is bad. It ’ s an excellent idea. It ’ s that we ’ re not doing BDD. And we ’ re certainly not doing BDD mechanisation.

2. BDD Automation Tools Create Extra Dependencies and Abstractions

Let ’ s direct a look at a diagram that shows the minimal quantity of habituation that are create when using a BDD automation framework (I didn ’ t include all the other dependencies such as test runners and so on, as they ’ re not related to BDD).

Source

If you were to not use Cucumber or another BDD automation tool, your dependencies for testing would look like this.

Source

In software development, we strive towards get our modules make less while fix the number of dependencies. Every colony is a chance for something to go wrong. Hence, at the core of most design patterns is the idea that you want to limit dependencies, includeSingle Responsibility Principle, Open-Closed Principle, YAGNIand so on.

So why are we adding spare BDD addiction and abstractions to our mechanisation if we aren ’ t following the process that was order by the BDD creators?

What function are we trying to achieve, to improve team collaboration or to use a instrument because it ’ s the hot new thing?

3. BDD tools struggle with parallelization

I think that we can all agree that parallelization is mandatory in today ’ s automation environs. If you want to ply any variety of decent coverage in a reasonable amount of clip, parallelization is mandatory (experience gratis to catch my presentation of parallelization).

Tools such asCucumber and SpecFlowdo parallelization in a sub-optimal manner. They parallelize at the feature file level. This implies that if you require to run 50 tests in analogue, you need to have 50 feature files. That ’ s a lot of feature file.

I have seen group that spend company time and money to plan a sharding mechanism that will split every test method into its own thread so that they can run scenario in parallel, rather than feature files.

If you use a BDD mechanization tool, you automatically have a disadvantage in exam automation. To overcome this disadvantage you must do extra work.

4. We are not actually writing correct Gherkin syntax

The argument that I see most frequently for the usage of BDD mechanization is that it makes the tests more readable. And then I see tryout like this:

(This is just a small and obfuscated sample of the BDD I see on a daily base.)

Please describe to me what this test is really corroborate from the end-user perspective?

The issue is that the bulk of us do not follow the correct Gherkin syntax as prescribed by the BDD Almighty. I get it, it ’ s hard. For example, hither are some of the rules:

• Write all steps in third-person point of view

• Write steps as a subject-predicate action phrase

• Given-When-Then stairs must appear in order and can not double

Source: https: //automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/

So the point of having more readable tests as a resultant of BDD exercise is really erroneous.

Conclusions

Why are we, as an industriousness, using a tool for test mechanisation that doesn ’ t provide any of the expected benefit, while at the same time creating more complexness?

As stated by the Cucumber certification, “ BDD aims tonarrow the communication gapsbetween team member,foster better agreement of the customer and promote uninterrupted communicatingwith existent domain examples ”. If we aren ’ t actually communicating more to promote a better understanding of the product, so it doesn ’ t make sense to add an automation creature that creates more complexity, hinders your power to parallelize well, and overall merely makes our life as automation engineers even harder.

Products

Globular tools

Set up and integrate

Resources

Company