Removing Cucumber from Automation Stack


We are looking at removing Cucumber for Java from our stack. We do not practice BDD and, therefore, would like to remove the extra dependencies. Wondering if anyone out there has gone through this process before and what advice they may have, how this process went for them, what the end result was.


1 Like

I have never done that. But I was wondering how you use cucumber without doing BDD. Have you tried to convert some tests to not use cucumber & see how that goes ?

Hi @schmadley,

Iโ€™m assuming that youโ€™re planning to remove gherkin/bdd and use other framework like testNg, junit5 etc with existing Java code.
Unfortunately, there is no easy or short answer to your question. It mostly depends on how SOLID your code is.

It would be relatively easy to switch the framework if:

  • page objects (if any) have the relevant methods on that pages and these methods follow single responsibility principle
  • step definition files have minimum or no low level code i.e. code for inputs, clicks, etc. Ideally all givens and when would be in the form of methods written in page objects. Thens/Assertions are usually one liners and could be in the step definition files. Hence moving them to new framework would be time consuming task
  • utils are portable (in most frameworks utils would be static classes and would be portable)
  • tests are atomic in nature (no two tests are dependent and one test does only one thing)

There are benefits of moving out of BDD if itโ€™s not likely to be used the way it should be. However, depending on the amount of effort you could afford, from high to low, you may want to think if it is more beneficial to:

  1. Move to completely different tool/language/framework that uses different architecture than selenium and provides few benefits like speed, easy mocking, full browser access etc.
  2. Move current code to new framework like testNg / JUnit. These are not perfect either. You could face challenges about effective reporting of tests/coverage etc if reporting is a thing at your place.
  3. Move only part of current framework outside BDD. E.g. it may be easier to move only API tests outside BDD for example.
  4. keep BDD and extend framework with additional useful features that provide more benefit e.g. mocking, containerization, cloud testing, performance,
  5. try to use BDD the way it should be. It does provide lot of benefits if used properly (you may tried this already)
1 Like

Thank you Yogesh for taking the time to reply to this open-ended question. We are in the exploratory phase and are assessing all of our options. These are great points to consider and weโ€™ll utilize them in our decision. Thanks again!

Hi Raghu - Our company utilized Cucumber as their introduction into test automation before I was here. They thought itโ€™d be a good way to get their manual QA into automation, but the product/dev teams have not adopted BDD. Itโ€™s really just my team converting manual test cases into Cucumber/Gherkin. We are trying to change the culture, and if we can get BDD engrained from top to bottom, we may still utilize it, but at the same time, we need to get to writing more atomic tests, get the team trained to be true SDETs, get away from testing through the UI so much, run more in parallel, etc., so moving away from Cucumber seems to make sense.
We have not converted any tests yet, still analyzing what we have and how to break it out.
Thanks for the reply!

Hi @schmadley.

Your questions triggers two things with me:

  1. It helps greatly if the step definitions are no more than a glue layer: the absolute minimum of code required to invoke logic elsewhere. That logic should be reusable just fine when switching to another framework (where I would normally expect a framework such as FitNesse to be preferred over junit).
  2. When removing dependencies on Cucumber libs from all but our step defs, we needed to adjust:
  • Any usage of the Cucumber DataTable (and possibly others) from our non-stepdef code. The easy way is to just convert the types of method parameters to List or List<List>.
  • Cucumber hooks such as @ Before and @ After. These can be trickier, but the first step is likely separating the annotations from the logic that performs the actions. So you end up with the hooks placed in one (Cucumber related) class and the logic of those actions in one or more other classes.

I hope this helps.

Awesome, thank you for sharing Martin!