{"id":15013061,"url":"https://github.com/ariesb/autokin","last_synced_at":"2025-10-31T07:33:18.584Z","repository":{"id":34013843,"uuid":"165155161","full_name":"ariesb/autokin","owner":"ariesb","description":"Easy to use gherkin-based scripting for non-developers to work or build REST API Automation testing without coding. ","archived":false,"fork":false,"pushed_at":"2022-12-06T15:02:25.000Z","size":3076,"stargazers_count":9,"open_issues_count":14,"forks_count":2,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-03-25T23:51:20.180Z","etag":null,"topics":["api","automation","bdd","contract-testing","gherkin","json-schema","puppeteer","response-schema","rest-api","rest-client","scenario","testing","web"],"latest_commit_sha":null,"homepage":"http://www.autokinjs.com","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ariesb.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2019-01-11T01:02:01.000Z","updated_at":"2022-06-06T15:50:16.000Z","dependencies_parsed_at":"2023-01-15T04:01:30.530Z","dependency_job_id":null,"html_url":"https://github.com/ariesb/autokin","commit_stats":null,"previous_names":[],"tags_count":7,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ariesb%2Fautokin","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ariesb%2Fautokin/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ariesb%2Fautokin/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ariesb%2Fautokin/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ariesb","download_url":"https://codeload.github.com/ariesb/autokin/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248514429,"owners_count":21116963,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["api","automation","bdd","contract-testing","gherkin","json-schema","puppeteer","response-schema","rest-api","rest-client","scenario","testing","web"],"created_at":"2024-09-24T19:43:40.847Z","updated_at":"2025-10-31T07:33:18.446Z","avatar_url":"https://github.com/ariesb.png","language":"JavaScript","readme":"[![Build Status](https://travis-ci.org/ariesb/autokin.svg?branch=master)](https://travis-ci.org/ariesb/autokin) [![Coverage Status](https://coveralls.io/repos/github/ariesb/autokin/badge.svg?branch=master)](https://coveralls.io/github/ariesb/autokin?branch=master)\n[![npm](https://img.shields.io/npm/v/autokin?color=#00CF91)](https://www.npmjs.com/package/autokin)\n\n# Autokin (Automation by Gherkin)\n\nThis is a simple package/library that helps tester to do automation of REST/API using Gherkin without knowing JavaScript coding. All you need to know is Gherkin and you can start working and creating automated test for contract testing, or simple API test.  \n\nMobile testing through Appium introduced starting in `v1.9.0`. Basic connection, navigation, and interaction are added to perform series of test on mobile applciations. See documentation for more detailed steps.\n\nIntroduced in `v1.8.0`, Autokin now supports web based automation using Puppeteer. You may now create Gherkin based test that targets browser application.\n\nOne of the simplest item that we do not want to missed is to break contract of front end apps to our service apps. To make sure that we can detect this easy and early on we want the following:\n\n:thumbsup: Validate each endpoints response schema.  \n:thumbsup: Validate possible response data.  \n:thumbsup: Validate data fetch with authentications.  \n:thumbsup: Enable chanining of multiple endpoint calls.  \n:thumbsup: Validate HTTP status code and header data.  \n:thumbsup: Ability to drive test using data.  \n:thumbsup: Supports data generation for inputs.  \n:thumbsup: Easy to write and not too technical.  \n:thumbsup: Easy to integrate with CI/CD environment.  \n:thumbsup: Supported with generated test reports.  \n\nIf these are something you need then Autokin can help you on that. Explore!\n\n## What's New\n* Ability to perform test om Mobile application through Appium server\n* Ability to perform test on Web application using Puppeteer\n* Ability to test response JSON Data against JSON Schema (https://json-schema.org/). [See example](#json-schema-comparison).\n* Allow pre-define variable set that can be loaded use within features\n* **Autokin Generators**: Ability to generate data randomly or based on certain list\n\n## Creating an Autokin Project\n\n### Make a project folder\n```bash\nmkdir my-autokin-project\n```\nName the folder anything that you see fit. Before proceeding to next step make sure that you are inside the new folder.\n\n```bash\ncd my-autokin-project\n```\n\nNext, let us install Autokin.\n\n### Install Autokin\nYou can simple do it by:\n```bash\nnpm install autokin --save-dev\n```\n\nThat simple, and now we are ready to create our first project. \n\n### Creating a project\nTo create a new Autokin project, run the following command.\n```bash\n./node_modules/.bin/autokin -i\n```\n\nThis will create the necessary folder structure and sample files.\n\n```json\n   my-autokin-project\n      ├── features\n      |    ├── support\n      |         ├── steps.js\n      |\n      └── first.feature\n```\n\nLet's run the test!\n\n### Running the test\nSimply, issue the command below to run the test.\n\n```bash\n./node_modules/.bin/autokin -e\n```\n\nIt should have the following output:\n```bash\n./node_modules/.bin/autokin -e\nAutokin Test Run\nFeature: My Feature \u003e My First Scenario - ✔ Passed\n\nTest Result Summary\n┌────────────┬────────┬───────────┬───────┐\n│ Features   │ Result │ Scenarios │ Steps │\n├────────────┼────────┼───────────┼───────┤\n│ My Feature │    --- │         1 │     0 │\n└────────────┴────────┴───────────┴───────┘\n\n┌────────────────────────┬────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┐\n│ Features / Scenarios   │ Result │ Steps │ Passed │ Failed │ Skipped │ Pending │ Ambiguous │ Unknown │\n├────────────────────────┴────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┤\n│ My Feature                                                                                          │\n├────────────────────────┬────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┤\n│      My First Scenario │ ---    │     0 │      0 │      0 │       0 │       0 │         0 │       0 │\n└────────────────────────┴────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┘\n```\n## Runtime Options\n| Options                            | Shortkey   | Description                                                           |\n|------------------------------------|------------|-----------------------------------------------------------------------|\n| `--version`                        | `-V`       | Display version number                                                |\n| `--init`                           | `-i`       | Initialised new Autokin project structure                             |\n| `--specs [path]`                   | `-s`       | Specify path location of features, --specs myfeatures                 |\n| `--exec`                           | `-e`       | Execute automation test                                               |\n| `--tags [tags]`                    | `-t`       | Use with --exec to specify which tags to run, example:\"@autokin\"      |\n| `--junit`                          | `-j`       | Output additional result file in JUnit format                         |\n| `--time`                           | `-d`       | Display duration execution for each steps                             |\n| `--formatter [cucumber-formatter]` | `-f`       | Use with --exec to specify custom cucumber formatter                  |\n| `--variable [file-path]`           | `-v`       | Use with --exec to specify variable set from json file                |\n| `--html [file-path]`               | `-w`       | Generate test result in html file format using Autokin HTML Formatter |\n| `--help`                           | `-h`       | Output usage in console                                               |\n| `--clean`                          | `-c`       | Deletes existing reports and snapshots before running new test.       |\n\n\n## Creating your first REST Gherkin\n\nFor example we do have an endpoint as https://reqres.in/api/users/2, which is to fetch a user information. So let's start writing our Feature and Scenario, open the `first.feature` file that was previously generated. The file should have the following content:\n\n```gherkin\n@autokin\nFeature: My Feature\n\tAs Autokin tester\n\tI want to verify that all API are working as they should\n\nScenario: My First Scenario\n```\n\nNow I want to say that I want to access the endpoint:\n\n```gherkin\n@autokin\nFeature: My Feature\n\tAs Autokin tester\n\tI want to verify that all API are working as they should\n\nScenario: My First Scenario\n    Given that a secure endpoint is up at reqres.in\n    When I GET /api/users/2\n```\nWe added 2 lines, first we define that we want to access a secure (https) endpoint at the domain `reqres.bin`. Then on the second line, we said that we want to do a `GET` to `/api/users/2`.\n\nAt this point we already access the endpoint, and we can run test.\n```bash\n./node_modules/.bin/autokin -e\nAutokin Test Run\nFeature: My Feature \u003e My First Scenario - ✔ Passed\n\nTest Result Summary\n┌────────────┬────────┬───────────┬───────┐\n│ Features   │ Result │ Scenarios │ Steps │\n├────────────┼────────┼───────────┼───────┤\n│ My Feature │    100 │         1 │     2 │\n└────────────┴────────┴───────────┴───────┘\n\n┌────────────────────────┬──────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┐\n│ Features / Scenarios   │ Result   │ Steps │ Passed │ Failed │ Skipped │ Pending │ Ambiguous │ Unknown │\n├────────────────────────┴──────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┤\n│ My Feature                                                                                            │\n├────────────────────────┬──────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┤\n│      My First Scenario │ ✔ Passed │     2 │      2 │      0 │       0 │       0 │         0 │       0 │\n└────────────────────────┴──────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┘\n```\n\nLet's add some test on it. We know that the endpoint will return a 200 status code. Let us add that as verification item, but instead of 200 we expect 400 for it to generate an error. We add the new step after the `When`.\n\n```gherkin\nScenario: My First Scenario\n    Given that a secure endpoint is up at reqres.in\n    When I GET /api/users/2\n    Then response status code should be 400\n```\nYes, it should be that sentence, we can only change the value that we expect. Let's run the test again.\n\n```\n./node_modules/.bin/autokin -e\nAutokin Test Run\nFeature: My Feature \u003e My First Scenario - ✖ Failed\n\nTest Result Summary\n┌────────────┬───────────────────┬───────────┬───────┐\n│ Features   │            Result │ Scenarios │ Steps │\n├────────────┼───────────────────┼───────────┼───────┤\n│ My Feature │ 66.66666666666666 │         1 │     3 │\n└────────────┴───────────────────┴───────────┴───────┘\n\n┌────────────────────────┬──────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┐\n│ Features / Scenarios   │ Result   │ Steps │ Passed │ Failed │ Skipped │ Pending │ Ambiguous │ Unknown │\n├────────────────────────┴──────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┤\n│ My Feature                                                                                            │\n├────────────────────────┬──────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┤\n│      My First Scenario │ ✖ Failed │     3 │      2 │      1 │       0 │       0 │         0 │       0 │\n└────────────────────────┴──────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┘\n```\n\nAs expected it will generate an error. Fixing the expected value to 200 and running the test will have a clean successful run.\n\n```gherkin\nScenario: My First Scenario\n    Given that a secure endpoint is up at reqres.in\n    When I GET /api/users/2\n    Then response status code should be 200\n```\nYes, it should be that sentence, we can only change the value that we expect. Let's run the test again.\n\n```\n./node_modules/.bin/autokin -e\nAutokin Test Run\nFeature: My Feature \u003e My First Scenario - ✔ Passed\n\nTest Result Summary\n┌────────────┬────────┬───────────┬───────┐\n│ Features   │ Result │ Scenarios │ Steps │\n├────────────┼────────┼───────────┼───────┤\n│ My Feature │    100 │         1 │     3 │\n└────────────┴────────┴───────────┴───────┘\n\n┌────────────────────────┬──────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┐\n│ Features / Scenarios   │ Result   │ Steps │ Passed │ Failed │ Skipped │ Pending │ Ambiguous │ Unknown │\n├────────────────────────┴──────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┤\n│ My Feature                                                                                            │\n├────────────────────────┬──────────┬───────┬────────┬────────┬─────────┬─────────┬───────────┬─────────┤\n│      My First Scenario │ ✔ Passed │     3 │      3 │      0 │       0 │       0 │         0 │       0 │\n└────────────────────────┴──────────┴───────┴────────┴────────┴─────────┴─────────┴───────────┴─────────┘\n```\n\n## Targetting Test with Tags\nLet say I have now several features like the two examples below:\n\n` my-first-feature.feature`\n```gherkin\n@core\nFeature: My Feature\n\tAs Autokin tester\n\tI want to verify that all API are working as they should\n\nScenario: My First Scenario\n    Given that a secure endpoint is up at reqres.in\n    When I GET /api/users/2\n```\nThe above feature file we tag that as `@core` feature, while below we tag that as `@fix-321` to denote that this is for the fix for `321 issue`.\n\n` my-second-feature.feature`\n```gherkin\n@fix-321\nFeature: My Feature\n\tAs Autokin tester\n\tI want to verify that all API are working as they should\n\nScenario: Verify if API does not accept character id\n    Given that a secure endpoint is up at reqres.in\n    When I GET /api/users/abc\n```\n\nSo now we want to run the test but only focus on running `@fix-321`. WE can do this by using the following command.\n\n```bash\n./node_modules/.bin/autokin -e -t @fix-321\n```\n\nIf we want to run only `@core` then we can use the following:\n```bash\n./node_modules/.bin/autokin -e -t @core\n```\nIf we are nto passing the tags `-t` or `--tags` parameter, it will run everything.\n\nWhat if we want to run everything but not the `@core`, then we can also use the following command:\n\n```bash\n./node_modules/.bin/autokin -e -t \"not @core\"\n```\n\nSee more about [tags](docs/TAGS.md).\n\n## Chaining\nChaining is a way to continue another test that was previously executed. This is some how the nearest to chaining scenarios for Autokin. Let us say that you want to Login the user then use the session token to retrieve user information.\n\n```http\n    POST https://www.autokinjs.com/login\n    Headers:\n    Content-Type: application/json\n    {\n        \"username\": \"juan\",\n        \"password\": \"p3dr0\"\n    }\n\n    Response:\n    {\n        \"sessionId\": \"2AA21boNhOM5zR3Xgn96qw==\"\n    }\n\n    GET https://www.autokinjs.com/user/1001\n    Headers: \n    Content-Type: application/json\n    SessionId: 2AA21boNhOM5zR3Xgn96qw==\n\n    Response:\n    {\n        \"id\": 1001,\n        \"name\": \"Juan Pedro\",\n        \"age\": 30 \n    }\n```\n\nSo having that we can have this Feature definition:\n\n```gherkin\n@chaining\nFeature: My Chaining Feature\n\tAs Autokin tester\n\tI want to verify that all API are working as they should\n\n    Scenario: Login to the system\n        Given that a secure endpoint is up at www.autokinjs.com\n        Given I set Content-Type header to application/json\n        Given I set the JSON body to \n        \"\"\"\n        {\n            \"username\": \"juan\",\n            \"password\": \"p3dr0\"\n        }\n        \"\"\"\n        When I POST /login\n        Then response status code should be 200\n        Then I keep the value of body path \"$.sessionId\" as \"userSessionToken\"\n\n    Scenario: Get user information\n        Given that a secure endpoint is up at www.autokinjs.com\n        Given I set Content-Type header to application/json\n        Given I set SessionId header from \"userSessionToken\"\n        When I GET /user/1001\n        Then response status code should be 200\n\n```\n\nAs you see in the above example, we login then we store the session token to a variable `userSessionToken`, the variable name can be anything as long as a one word. Following to our next scenario, as needed by our API, we set the header `SessionId` to the value of the previously stored data by sepcifying that we are getting the stored value from the variable `userSessionToken`.\n\n## JSON Schema Comparison\nIt is important that contracts among consumer of the API ensure that the data expected are always correct. With this JSON Schema comparison, we can add assertion on the response data if it conforms to expected schema. We can store the schema to a file and use that as expected schema.\n\n```http\n    GET https://reqres.in/api/users?page=2\n\n    Response:\n    {\n    \"page\": 2,\n    \"per_page\": 3,\n    \"total\": 12,\n    \"total_pages\": 4,\n    \"data\": [\n        {\n            \"id\": 4,\n            \"email\": \"eve.holt@reqres.in\",\n            \"first_name\": \"Eve\",\n            \"last_name\": \"Holt\",\n            \"avatar\": \"https://s3.amazonaws.com/uifaces/faces/twitter/marcoramires/128.jpg\"\n        },\n        {\n            \"id\": 5,\n            \"email\": \"charles.morris@reqres.in\",\n            \"first_name\": \"Charles\",\n            \"last_name\": \"Morris\",\n            \"avatar\": \"https://s3.amazonaws.com/uifaces/faces/twitter/stephenmoon/128.jpg\"\n        },\n        {\n            \"id\": 6,\n            \"email\": \"tracey.ramos@reqres.in\",\n            \"first_name\": \"Tracey\",\n            \"last_name\": \"Ramos\",\n            \"avatar\": \"https://s3.amazonaws.com/uifaces/faces/twitter/bigmancho/128.jpg\"\n        }\n    ]\n}\n```\n\n**Expected Login Response Schema**\n\n`feature/schema/reqres-response-schema.json`\n```json\n{\n    \"definitions\": {},\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"$id\": \"http://example.com/root.json\",\n    \"type\": \"object\",\n    \"title\": \"The Root Schema\",\n    \"required\": [\n        \"page\",\n        \"max_page\",\n        \"per_page\",\n        \"total\",\n        \"total_pages\",\n        \"data\"\n    ],\n    ....\n               \"items\": {\n                \"$id\": \"#/properties/data/items\",\n                \"type\": \"object\",\n                \"title\": \"The Items Schema\",\n                \"required\": [\n                    \"id\",\n                    \"email\",\n                    \"first_name\",\n                    \"last_name\",\n                    \"avatar\"\n                ],\n                \"properties\": {\n                    \"id\": {\n                        \"$id\": \"#/properties/data/items/properties/id\",\n                        \"type\": \"string\",\n                        \"default\": 0,\n                        \"pattern\": \"^(.*)$\"\n                    },\n                    \"email\": {\n    ...\n}\n```\n\nIn the above Schema, it expects that `max_page` should be required and must be with the response, however the example of our response does not contain it, so we expect that this will be reported on our test. Aside from that, in the schema it also described that `id` in the `items` are `string` but we will be receiving `number` instead hence this should also be reported. \n\n```gherkin\n@schemachecks\nFeature: Bad Schema Feature Example\n\tAs Autokin tester\n\tI want to verify that all API contracts are correct\n\n    Scenario: Perform check on bad schema\n        Given that a secure endpoint is up at reqres.in\n        Given I set Content-Type header to application/json\n        When I GET /api/users?page=2\n        Then response status code should be 200\n        Then I expect response data schema complies to \"{schemaBasePath}/resreq-users-schema.json\"\n\n```\nThe last line of our test is a check for Schema compliance. Here Autokin will validate if the response does conforms with our expected schema, if not it should report all errors. Below is an example, where exact error will be presented along with the line numbers if available, so that it will be easier for us to debug and identify the problem.\n\n![Bad Schema - JSON Line Details](docs/images/bad_schema.png)\n\n## Pre-define Variable Set\nIin most case we do not want to hard code values in our test and we want to control the value based on certain environment to run it. You can specify pre-defined variable set using a JSON file.\n\n**Pre-defined Staging Environment Variables**\n```features/data/uat.variables.json```\n```json\n{\n  \"host\": \"www.uat.autokinjs.com\",\n  \"username\": \"autokin\"\n}\n```\n\nFor example above is our variable set, and we have 2 key-value that we can use within our test. Using the above anticipated variables, the following can be our test:\n```gherkin\nFeature: My Feature\n\tAs Autokin tester\n\tI want to verify that all API are working as they should\n\n    Scenario: Login to the system\n        Given that a secure endpoint is up at {host}\n        Given I set Content-Type header to application/json\n        Given I set the JSON body to \n        \"\"\"\n        {\n            \"username\": \"{username}\",\n            \"password\": \"p3dr0\"\n        }\n        \"\"\"\n        When I POST /login\n        Then response status code should be 200\n        Then I keep the value of body path \"$.sessionId\" as \"userSessionToken\"\n```\n\nIn the above example, we can use the variable by using curly braces to enclose our variable name, such as ``{host}``. In the example above, we used the variable as our source for the ``host``, and we also used another variable in the ``username`` as part of the body.\n\n**Specifying pre-define variable in runtime**\n```bash\n./node_modules/.bin/autokin -e -v ./features/data/uat.variables.json\n```\n  \n## Autokin Generators\nIn some cases we want to include auto generated data as part of the API request, some of these are emails, ids, names, and maybe passwords. With Autokin Generators, this can be done as well with minimal syntax to understand.\n\n**Generate Email Addresses**\n```gherkin\n    Scenario: Login to the system\n        Given that a secure endpoint is up at {host}\n        Given I set Content-Type header to application/json\n        Given I set the JSON body to \n        \"\"\"\n        {\n            \"username\": \"{generate:email(gmail.com)}\",\n            \"password\": \"p3dr0\"\n        }\n        \"\"\"\n        When I POST /login\n```\n\n**Generate Passwords**\n```gherkin\n    Scenario: Login to the system\n        Given that a secure endpoint is up at {host}\n        Given I set Content-Type header to application/json\n        Given I set the JSON body to \n        \"\"\"\n        {\n            \"username\": \"me@gmail.com\",\n            \"password\": \"{generate:any(8,numbers,uppercase,lowercase)}\"\n        }\n        \"\"\"\n        When I POST /login\n```\nThis will generate password with length of 8 characters that can be either `numbers`, `uppercase` letters, or `lowercase` letters. If you want `symbols` just add it from the list.\n\n**Generate Names**\n```gherkin\n    Scenario: Create Customer to the system\n        Given that a secure endpoint is up at {host}\n        Given I set Content-Type header to application/json\n        Given I set the JSON body to \n        \"\"\"\n        {\n            \"username\": \"{generate:emails(gmail.com)}\",\n            \"password\": \"{generate:any(8,numbers,uppercase,lowercase)}\",\n            \"firstname\": \"{generate:firstname(male)}\",\n            \"lastname\": \"{generate:lastname}\"\n        }\n        \"\"\"\n        When I POST /create\n```\n### Autokin Generators\n| Generator  | Description  |\n|---|---|\n| `{generate:email(domain)}`    | Generate random emails, with specified domain name. If not supplied it will have `autokinjs.com` as email domain.   |\n| `{generate:firstname()}`    | Generate firstname base on existing name list, it can be either male or female.    |\n| `{generate:firstname(male)}`    | Generate male firstname.    |\n| `{generate:firstname(female)}`    | Generate female firstname.    |\n| `{generate:lastname}`    | Generate lastname base on existing list.    |\n| `{generate:uuid}`    | Generate UUID v4.    |\n| `{generate:any(length, ...options )}`    | Generate random characters based on length and options. \u003cbr /\u003e\u003cbr /\u003eOptions can be `numbers`, `lowercase`, `uppercase`, or `symbols`.  \u003cbr /\u003e\u003cbr /\u003eTo generate only symbols: `{generate:any(10,symbols)}`. \u003cbr /\u003e\u003cbr /\u003eIf you want both `numbers` and `symbols`: `{generate:any(10,numbers,symbols)}`    |\n\nSee more [examples](docs/examples).\n\n## Autokin Gherkin Steps\nThere are several steps that we can use to combine different test, expectations, and behaviour that is needed in our test. Here are the list of steps:\n\n### Given\n| Step  | Description  |\n|---|---|\n| Given that a secure endpoint is up at {domain}    | Secured Endpoint Domain (https)   |\n| Given that a endpoint is up at {domain}           | HTTP only Endpoint Domain         |\n| Given I set {name} header to {value}              | Add headers  |\n| Given I set {name} header from {stored value name} | Add header with value from stored value  |\n| Given I set headers to                            | Add multiple headers |\n| Given I set query parameters to                   | Add query parameters |\n| Given I set query parameter {name} to {value}     | Add query parameter |\n| Given I set query parameter {name} from {stored value name}     | Add query parameter from the stored value |\n| Given I set the JSON body to                      | Set the body of the request |\n| Given I set the cookie to {cookie value pair}     | Add cookie value |\n| Given I set the cookie {name} to {value}  | Add cookie value |\n| Given I set the cookie {name} from {stored value name}  | Add cookie with value from stored value |\n| Given I have basic authentication credentials {username} and {password} | Set basic authentication |\n| Given I set the bearer token to {token} | Sets bearer token |\n| Given I set the bearer token with {stored value name} | Sets bearer token with stored value |\n| Given I set the request timeout to {timeout} seconds | Sets request timeout limit |\n\n### When\n| Step  | Description  |\n|---|---|\n| When I GET {uri} | Do a GET request |\n| When I POST to {uri} | Do a POST request |\n| When I PUT to {uri} | Do a PUT request |\n| When I perform DELETE to {uri} | Do a DELETE request |\n| When I PATCH to {uri} | Do a PATCH request |\n\n### Then\n| Step  | Description  |\n|---|---|\n| Then response status code should be {expected status code} |  Assert for response status code |\n| Then response status code should not be {expected status code} | Assert that response status code must not be equat to the expected |\n| Then response header {name} should exist | Assert if header exist from response |\n| Then response header {name} should not exist | Assert that header must not exist from response |\n| Then response header {name} should be {expected value}| Assert that the header from response must have the value expected |\n| Then response header {name} should not be {expected value} | Assert that the header must not have the value expected |\n| Then response body should be valid json | Assert that response should have a JSON body |\n| Then response body should be json data of | Assert if the expected JSON data is the same with the response body |\n| Then I expect that path {path} from body has value of {expected value}|  Assert JSON body if the path specified has the expected value |\n| Then response body should have path {path} | Assert if path exist from JSON body |\n| Then response time is not greater than {response time}ms | Assert if response time is not greater than expected |\n| Then response time is greater than {response time}ms | Assert if response time is greater than expected |\n| Then I keep the value of body path {path} as {storage name}| Store the value of the path as the specified storage name |\n| Then I keep the value of header {name} as {storage name} |  Store the value of the header as the specified storage name |\n| Then I expect that the stored value in {storage name} is {expected value}|  Assert if the stored name has the expected value |\n| Then I expect response data schema complies to {schema path} |  Assert if the response JSON body complies to JSON schema file |\n\nFor complete examples, [see docs ](docs).\n\n","funding_links":[],"categories":["JavaScript"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fariesb%2Fautokin","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fariesb%2Fautokin","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fariesb%2Fautokin/lists"}