Start	| Maven | Cucumber vs Karate |
Run	| Command Line | Suites | Reporting | Troubleshooting |
Advanced	| Contributing |

Maven

The Framework uses Spring Boot Test and Karate, client implementations.

Spring <dependencies>:

<dependecies>
    ...
        <dependency>
            <groupId>org.springframework.amqp</groupId>
            <artifactId>spring-rabbit</artifactId>
            <version>${spring-rabbit.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
        </dependency>
    ...
</dependecies>

Karate <dependencies>:

<dependecies>
    ...
    <dependency>
            <groupId>com.intuit.karate</groupId>
            <artifactId>karate-apache</artifactId>
            <version>${karate.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.intuit.karate</groupId>
            <artifactId>karate-junit5</artifactId>
            <version>${karate.version}</version>
            <scope>test</scope>
        </dependency>
    ...
</dependecies>

Command Line

Normally you will use your IDE to run a *.feature file directly or via the *Test.java class. With the Test class, we can run tests from the command-line as well.

Note that the mvn test command only runs test classes that follow the *Test.java naming convention.

You can run a single test or a suite or tests like so :

mvn test -Dtest=HeroKarateTest

Note that the mvn clean install command runs all test Classes that follow the *Test.java naming convention

mvn clean install

JUnit Suites

By using the JUnit Framework, we can execute multiple Modules in a single test run

Right click the JunitSuiteTest class and select Run

@RunWith(JUnitPlatform.class)
@SelectClasses({
        BasicParallelKarateTest.class,
        DynamicParallelKarateTest.class
})
public class JunitSuiteTest {

    @Test
    @Ignore
    public void foo(){}
}

Configuration

The AbstractTestDefinition class is responsible for specifying each Step class as @SpringBootTest and its @ContextConfiguration

All the Step Classes in the Framework should extend the AbstractTestDefinition class

@ContextConfiguration(classes = {KarateContextConfiguration.class})
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)
public class AbstractTestDefinition { }

The KarateContextConfiguration class is responsible for specifying the Spring @Configuration, modules to scan, properties to use etc

@Configuration
@ComponentScan({
        "cmccarthyirl"
})
@PropertySource("classpath:/application.properties")
public class KarateContextConfiguration {
}

Environment Switching

There is only one thing you need to do to switch the environment - which is to set <activeByDefault> property in the Master POM.

By default, the value of spring.profiles.active is defined in the application.properties file which inherits its value from the Master POM property <activeByDefault>

 <profiles>
        ...
        <profile>
            <id>prod</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <activatedProperties>prod</activatedProperties>
            </properties>
        </profile>
        ...
</profiles>

You can then specify the profile to use when running Maven from the command line like so:

mvn clean install -P dev

Below is an example of the application.properties file.

spring.profiles.active=@activatedProperties@

Cucumber HTML Reports

The Framework uses Cucumber HTML Reports

Cucumber vs Karate

Karate was based on Cucumber-JVM until version 0.8.0 but the parser and engine were re-written from scratch in 0.9.0 onwards. So we use the same Gherkin syntax - but the similarity ends there.

If you are familiar with Cucumber (JVM), you may be wondering if you need to write step-definitions. The answer is no.

Karate's approach is that all the step-definitions you need in order to work with HTTP, JSON and XML have been already implemented. And since you can easily extend Karate using JavaScript, there is no need to compile Java code any more.

The following table summarizes some key differences between Cucumber and Karate.

▫️	Cucumber	Karate
Step Definitions Built-In	No. You need to keep implementing them as your functionality grows. This can get very tedious, especially since for dependency-injection, you are on your own.	✅ Yes. No extra Java code needed.
Single Layer of Code To Maintain	No. There are 2 Layers. The Gherkin spec or *.feature files make up one layer, and you will also have the corresponding Java step-definitions.	✅ Yes. Only 1 layer of Karate-script (based on Gherkin).
Readable Specification	Yes. Cucumber will read like natural language if you implement the step-definitions right.	❌ No. Although Karate is simple, and a true DSL, it is ultimately a mini-programming language. But it is perfect for testing web-services at the level of HTTP requests and responses.
Re-Use Feature Files	No. Cucumber does not support being able to call (and thus re-use) other *.feature files from a test-script.	✅ Yes.
Dynamic Data-Driven Testing	No. Cucumber's Scenario Outline expects the Examples to contain a fixed set of rows.	✅ Yes. Karate's support for calling other *.feature files allows you to use a JSON array as the data-source and you can use JSON or even CSV directly in a data-driven Scenario Outline.
Parallel Execution	No. There are some challenges (especially with reporting) and you can find various discussions and third-party projects on the web that attempt to close this gap: 1 2 3 4 5 6 7 8	✅ Yes. Karate runs even Scenario-s in parallel, not just Feature-s.
Run 'Set-Up' Routines Only Once	No. Cucumber has a limitation where Background steps are re-run for every Scenario and worse - even for every Examples row within a Scenario Outline. This has been a highly-requested open issue for a long time.	✅ Yes.
Embedded JavaScript Engine	No. And you have to roll your own approach to environment-specific configuration and worry about dependency-injection.	✅ Yes. Easily define all environments in a single file and share variables across all scenarios. Full script-ability via JS or Java interop.

Troubleshooting

• Execute the following commands to resolve any dependency issues
  1. cd ~/install directory path/spring-karate-test-harness
  2. mvn clean install -DskipTests
  3. execute the Karate test

Contributing

Spotted a mistake? Questions? Suggestions?

Open an Issue