Testing with Karate Knocks
Test is never enough nowadays and implement integration test sometimes is a little bit “boring”. So, why not to make use of a bunch karate knocks to speed up your web service tests and make your life easy? Let’s see a brief introduction about karate framework:
Karate enables you to script a sequence of calls to any kind of web-service and assert that the responses are as expected. It makes it really easy to build complex request payloads, traverse data within the responses, and chain data from responses into the next request. Karate’s payload validation engine can perform a ‘smart compare’ of two JSON or XML documents without being affected by white-space or the order in which data-elements actually appear, and you can opt to ignore fields that you choose.
Since Karate is built on top of Cucumber-JVM, you can run tests and generate reports like any standard Java project. But instead of Java — you write tests in a language designed to make dealing with HTTP, JSON or XML — simple.
Ok, show me the code! We’ll spin up a local server with json-server acting as our target web-service.
Create your awesome database as a json file:
Now let json-server spin-up a web-service automagically:
npm install json-server -g
json-server mydb.json
Now we have our awesome service to perform a few tests with the powerful karate. To start coding, we’ll need:
- Java 8
- Maven (oh, really?)
- Karate — Webservices testing with BDD-Like aproach
- Junit
- Json-server — easy to use local mock server
Instalation
Let’s create a new project with karate maven archetype:
mvn archetype:generate \
-DarchetypeGroupId=com.intuit.karate \
-DarchetypeArtifactId=karate-archetype \
-DarchetypeVersion=0.6.1 \
-DgroupId=cme.viniciuspiedade \
-DartifactId=myproject-qa
Let’s make a small change on the pom.xml adding entries to testResources tag:
Now we have a basic karate project structure. Yeah!
Project structure
We’ll use the project structure conventions based on Karate-Demo but with a few differences. First: your project classpath structure must consider the src/test/resources folder as a source folder because all karate config files are stored inside this folder and they need to be at the root path of your test-classes like this:
- src/main/java (Created by default for maven projects)
- src/test/resources (Where all karate config files will live. We have to move karate-config.js and hogback-test.xml for this folder)
- src/test/java (Where your features and tests will be organized. You can see an example created by karate maven archetype)
Here you can see an example of what is the power behind Karate framework:
With a single *.feature file with a Gherkin-like language we can define a test against the ‘/posts’ endpoint performing a POST with a post payload defined on the request body, asserting that it’ll return the HTTP status 200 and the response body matches the expected post specification. Karate will interpret your Gherkin file with the power of Cucumber behind the scenes with it’s builtin StepDefinitions and will prepare request calls with all availble http methods, deal with json and xml contents and http headers, make assertions with response with it’s powerfull jsonPath matcher and a lot more.
Organizing your feature files
Karate provides a flexible way to run your feature files: it’ll run all files from above your current Java Test class recursively (including subfolders/packages). Based on this we’ll organize our features on consumer and functionality hierarchy like bellow:
Let’s understand more about this project structure: on the root package we have our consumers folders, one folder for each consumer and inside the root of each consumer folder we’ll have a Consumer Junit Test class responsible to run all tests for it’s consumer organized into funcionalities (each functionality with separetad folder) from maven command line. Inside each funcionality we have one Junit class file but with a Runner suffix and one or more feature files. It means that you can run all features of this functionality of a specific consumer only through your local IDE (eg. eclipse) running the *Runner.java class as a Junit Test class.
Run all features as a regressive test:
mvn test
Run all features of the consumer1:
mvn test -Dtest=consumer1.Consumer1Test
Run all features of consumer1 posts functinality:
mvn test -Dtest=consumer1.posts.PostsCRUDRunner
Configuring Karate
Now we’ll make a few improvements @ karate config files to make it easy to use on our projects. Below you’ll see all steps to configure karate using the Buscapé convention:
karate-config.js
Our karate-config.js file will look like this.
With this config file we are defining different a baseUrl based on an environment variable called karate.env. If it’s filled with homolog value, all requests will hit our fake homolog server http://homolog.myserver.com and if no value was found for karate.env it will look to our local server (on this case, our json-server). We are able to provide a different mock server port or leave it as default 3000.
Coding our features
Let’s code our first feature of Consumer1: Post C.R.U.D.
To make this post smaller and easy to read, check the project link on GitHub below to see all other feature files.
Running your first test locally with json-server
$ mvn test
You can specify the mock server port with -Dmock.server.port argument:
$ mvn test -DargLine=”-Dmock.server.port=8080"
Running your tests pointing for the homolog server
$ mvn test -DargLine=”-Dkarate.env=homolog”
You’re done!
That’s it! Karate is an awesome project and I’ll really appreciate if you spend a little time looking his GitHub. You can create automated integration tests pipelines with it inside your current CI/CD stack very easy. Check this project at my GitHub here too and enjoy with Integration Tests!
Hope you enjoy it!
See ya!
