Karate Framework Usage Guidelines are as follows-
Project Structure
Each project is structured as follows:
- src (contains global config & js utils)
- /main
- /java/com/ddaqe (contains utility functions)
- /resources (contains supporting jars and files)
- /test
- /java
- /oneService (contain test runners and feature files)
- /data (contains test data files for oneService)
- /anotherService (contains test runners and feature files)
- /data (contains test data files for anotherService)
Creating new tests
Project structure must be maintained.
Environment, accounts and database info are parameterized and defined in karate-config.js file.
Each feature file:
must be independent and atomic
must contain:
- Feature
- Background (anything defined here applies to all scenarios in the feature file)
- Scenarios and/or Scenario Outlines
should retain consistent formatting to maintain readability: right-click a feature file > Pretty Format (or Ctrl+Shift+F)
Each scenario in a feature file must:
- be independent of other scenarios and able to run in any order
- be data-driven when appropriate (refer to https://github.com/intuit/karate#data-driven-tests)
- have all data files go in '[package_name]/data' folder
- be tagged with @smoke if it is a smoke test
When a script creates new content in the application under test, prefix the content with "qeauto-" when possible so that it can be identified for deletion later.
Example Karate scripts: https://github.com/intuit/karate/tree/master/karate-demo
Naming Folders & Files
(Refer to attached screenshot for examples)
- Name folders and files using lower Camel Case (Camel case starting with lowercase).
- Name data files in lowercase with hyphen.
- Services should be named based on Swagger doc information, so that names match. Example: for user details service, package name would be "userDetailsService".
- Service folder must contain Regression, Smoke and Service runners. Simply replicate from existing copy.
- Sub-folders are added under the service package for each endpoint path. Example: for /terms path, you create "userDetailsService\terms".
- Feature files are added in the endpoint folder and names after the endpoint. Where multiple feature files are needed for one endpoint, append an underscore before extending the name. Example: "terms_IncorrectHeaders"
Naming Tests
The way test scripts are named is critical. These are used to report the test run status via scripts back to Adaptavist. The naming convention below must be followed to avoid incorrect reporting.
- Each scenario description must be prefixed with the test case id, followed by a colon (with no spaces before the colon). Example for Adaptavist test case id IRIS-T223:
Feature: To Test Valuation API
I want to verify the /lookup/valuation endpoint returns all valuation records.
Background:
* url baseUrl
* header Authorization = auth
* path '/lookup/valuation'
Scenario: IRIS-T223: GET /lookup/valuation - All valuation records
Given request ''
When method get
Then status 200
- Some test cases belong to same functional areas or screens can be merged in a single automation script. In this case, the test case ids should be separated by underscore and represented in the format "ID1_ID2_ID3_...". This should be rare for API tests.
- Larger manual test case can be split into multiple test scripts. In this case, test case ids should be represented in format "ID_1, ID_2, ...". This should be rare for API tests.
NOTE:
You cannot mix #2 and #3.
Naming Variables
Within feature files, name variables in all lowercase with underscore as the word separator. Example "project_url" instead of "projectUrl".
Setting up reusable features
When a set of steps needs to be repeated in multiple scripts, create reusable scenarios:
- Create a reusable feature file in the applicable service package
- Prefix filename with "common_"
- Add the reusable scenario to this file
- Add @ignore tag to the scenario in the file
- Call the feature file from your test. Refer to examples in docs.