Library for testing api endpoints
Project description
contract-test-framework contains an implementation of contract testing in Python with support for REST and gRPC. Under the package name fellowship
How to use from console
REST
If you want to validate a REST API, run Fellowship in validate mode. If your contracts follow the Jinja2 syntax, make sure that you give the path to config.yaml in environment variable contract_test_config. You can see examples of contracts and config at example_contract.json. Request part of the contract specifies the endpoint to make the request to. While everything under properties defines the JSON schema to validate against. Fellowship validates these contracts against a meta-schema before it makes the request. Example of how to run from console:
$ fellowship validate path/to/contract_directory/
To generate a contract in console, run in generate mode, with the following syntax:: fellowship generate path_of_the contract_to_generate request_kwargs expected_json. Request_kwargs is the request as a dictionary, the dictionary can take following parameters:
url: can be given as a full url, or just the endpoint (/api/v1/test)it will then fill out the Jinja 2 syntax for you{{ config.protocol }}://{{ config.host}}/api/v1/test, when validatingprotocol and config will be filled from config.yaml headers: can be given as a dictionary {“Accept”: “application/json”}, ifleft empty it will automatically fill as{{ config.default_headers | jsonify }}.data: The body of the request
The last expected argument is the expected json response from the Rest API. The contract will generate with only types and required for all fields. If you want to validate the values, you need to fill the consts and enums manually.
$ fellowship generate sample.json '{"url": "/test", "method": "GET"}' \
'{"json": "expected_response"}'
gRPC
For gRPC validation, run Fellowship in validate gRPC mode. It takes the same syntax as validate for REST. But make sure that you only have one type of contracts in the directory that you validate.
To generate gRPC contracts you run Fellowship in generate_grpc mode. It takes the output directory path as first argument and the proto file to use as a basis for generation as second argument. It will generate contracts for all services and all their functions. The contracts will be output to directory given in the path argument.
Features
gRPC and REST endpoint contract testing and contract rendering.
Future development plans includes to support message-based communication
Installation
fellowship is available on PyPI. You can install using pip:
$ pip install fellowship
Running the Test Suite
If you have tox installed (perhaps via pip install tox or your package manager), running tox in the directory of your source checkout will run fellowship’s test suite.
Contributing
See how to contribute in CONTRIBUTING.rst.
The code and the issues are hosted on GitHub.
The project is licensed under BSD-3-Clause.
The documentation is hosted on read the docs
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
File details
Details for the file fellowship-0.1.0.tar.gz
.
File metadata
- Download URL: fellowship-0.1.0.tar.gz
- Upload date:
- Size: 21.7 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/3.4.2 importlib_metadata/4.8.1 pkginfo/1.7.1 requests/2.26.0 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.9.7
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | bfb9c16e8b5d824c729c2bfa0dbd49dd44285b87c57f77d61222741474dc35e6 |
|
MD5 | cbb9d590a1ce54794ffe09319ee24c8b |
|
BLAKE2b-256 | e0e30e227563703c49e89b3a57544db27ac556c9f94946ac9cc63b9c938f7032 |