Cucumber-JVM Hello world with Gradle

Filed under: Cucumber, Gradle, Maven, — Tags: Automation, Cucumber-jvm — Thomas Sundberg — 2014-08-24

Cucumber is very easy to run from Maven. How do you run it from Gradle?

The answer to this question is: It is as easy as to run it from Maven. Depending on your background, perhaps even easier. The reason for this is because we run Cucumber from a JUnit runner. That is as a unit test with a specific runner. Maven or Gradle really doesn't have anything to do with this. It all boils down to the need for a Gradle project that can build a Java project. A Java project that has a unit test.

A Gradle project that will build and run Cucumber could look like this:

build.gradle

apply plugin: 'java'

version = '1.0-SNAPSHOT'

dependencies {
    testCompile 'junit:junit:4.11',
            'info.cukes:cucumber-java:1.1.8',
            'info.cukes:cucumber-junit:1.1.8'
}

repositories {
    mavenCentral()
}

The first thing I do is applying the Java plugin. This plugin will build a Java project. A Java project where the file structure is assumed to be the same structure as a Maven Java project. Gradle isn't built for just coping with Java projects, you can build almost any project with it. Therefore I have to define that this will be a Java project.

Next thing to define is the version of the project. This could be anything, I use 1.0-SNAPSHOT here.

The next section defines a few dependencies that are needed. We need JUnit so we can run Cucumber from a JUnit class. We also need some Cucumber stuff. We need Cucumber for Java and we need the Cucumber JUnit runner.

The final thing needed is to define where Gradle should find the dependencies defined above. Gradle is, as Maven, all about conventions but it isn't Maven so it doesn't have a default repository manager for dependencies. I have to specify the repositories where Gradle should look for dependencies. I made my life easy here and specified The Central Repository.

Next thing is to build the project so that Cucumber is executed. The Java plugin has added a few build tasks that we can use to build. I will use the build task from the root of the project. That is the same directory where build.gradle lives.

    gradle build

The result is a build of the the entire project where the tests are executed.

The same thing is possible to achieve using Maven and this pom:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>se.thinkcode</groupId>
    <artifactId>cucumber-itake-unconference-2014</artifactId>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
            <groupId>info.cukes</groupId>
            <artifactId>cucumber-java</artifactId>
            <version>1.1.7</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>info.cukes</groupId>
            <artifactId>cucumber-junit</artifactId>
            <version>1.1.7</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

To run this Maven project, do:

    mvn package

The entire example can be implemented as I did at the I T.A.K.E. Unconference in Bucharest May 2014. I used Maven there, in this case I used Gradle.

Conclusion

The Gradle project file is smaller than the Maven project file. They both do the same thing, build a Java project and execute the unit tests.

Running Cucumber using Gradle is more about how to build a Java project using Gradle than anything else.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS