A little while ago (ok, maybe in the distant past), I started writing about Cucumber. My very first post detailed how to set up Cucumber-JVM, and we’ve come a long way from then. I thought it was worth revisiting, as there are simpler ways to get setup, and better tools out there to use. So with that, let’s dive back in!

Build Tools

Previously, I was setting up the project by manually identifying and downloading each of the required jars into a lib directory. That is so last decade to do things. What we should be doing is orchestrating and controlling these dependencies with a build tool.

Enter tools like Maven, Gradle, or even Ant. These tools can not only help build your software, but they can also build your tests, and manage their dependencies. So, instead of downloading the required Cucumber libraries, let’s just identify them in our build tool. For this example, we’ll use Maven, but it’s incredibly simple to apply these same added blocks to any other tool.

Ideally, your tests will be integrated into the same project as the developed application, so there should already be a pom.xml file that exists. First thing to do is to add Cucumber as a dependency. Simply update your pom.xml file to include (or add the dependency block to your current dependencies):

<!-- https://mvnrepository.com/artifact/io.cucumber/cucumber-jvm -->
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-jvm</artifactId>
<version>2.0.0</version>
<type>pom</type>
</dependency>

<!-- https://mvnrepository.com/artifact/info.cukes/cucumber-testng -->
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-testng</artifactId>
<version>1.2.5</version>
</dependency>

I personally prefer to use Cucumber built off of TestNG, but if you’d rather use it built off of JUnit, that’s easy enough to switch up, it’s just a simple dependency change (much easier than before). And that’s it; nothing to download, no other setup needed. The rest of my old post can be re-used.

Expand Capabilities

But this would be a pretty lame post if that was all there was, right? Luckily, I have a few more thoughts to impart. In a different previous post, I talked about using dependency injectors to simplify your code base. If you want to use them again, no need to stress out about it; simply add the dependency to your pom.xml file.

<!-- https://mvnrepository.com/artifact/info.cukes/cucumber-picocontainer -->
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-picocontainer</artifactId>
<version>1.2.5</version>
</dependency>

It’s as easy as copy/paste! If you want the Selenium dependencies we used last time, just another block to add.

<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.version}</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-server -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-server</artifactId>
<version>${selenium.version}</version>
</dependency>

<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>3.3.0</version>
</dependency>

You’ll notice I added a webdrivermanager dependency in this one. Stay tuned for an upcoming post on how to use it.

Outside the Box

One of my big pet peeves has always been the parallelization of test execution for Cucumber. There are a few ugly ways to do it, however, they require multiple custom runners to get it done and become un-maintainable fast (think one runner per feature or even scenario). Luckily, there is a better way!

There is a wonderful Maven plugin by temyers that auto-generates test runners, so that you don’t need to. In fact, in that first post I linked to, you don’t even need the Generic Test Runner at all, this plugin will create it all for you. Less code = better! All you need to do is to add a plugin to your pom.xml file.

<plugin>
<groupId>com.github.temyers</groupId>
<artifactId>cucumber-jvm-parallel-plugin</artifactId>
<version>4.2.0</version>
<executions>
<execution>
<id>generateRunners</id>
<phase>generate-test-sources</phase>
<goals>
<goal>generateRunners</goal>
</goals>
<configuration>
<glue>
<package>com.coveros</package>
</glue>
<plugins>
<plugin>
<name>json</name>
</plugin>
<plugin>
<name>html</name>
</plugin>
</plugins>
<useTestNG>true</useTestNG>
<namingScheme>feature-title</namingScheme>
<parallelScheme>SCENARIO</parallelScheme>
<tags>
<tag>~@wip</tag>
</tags>
</configuration>
</execution>
</executions>
</plugin>

And that’s it! Now, each scenario and every scenario outline example can run happily in parallel with each other.

Wrap Up

So, for my tl;dr, there are lots of great plugins out there for your Cucumber code, and using Maven (or Gradle or Ant), will make it really easy to use these tools, and boost your framework’s power. Stay tuned for my next post on using a custom Listener class to allow for further control beyond Cucumber’s @Before and @After hooks.

As always, leave comments below!

Leave a comment

Your email address will not be published. Required fields are marked *

X