Download the PHP package chstudio/raven without Composer

Raven - How to test your API documentation and behavior.

This library was written to allow testing OpenAPI documentation easily. It also allows verifying that your code implementation is compatible with that documentation.

Why creating such tool ?

We work a lot on API related projects. Sometimes we create API, sometimes we consume them. The OpenAPI description format is now well known and used in a lot of different contexts.

Our concern is that it's hard to ensure that the written documentation is representing the current API behavior. We wanted to track the implementation difference between the doc and the code.

We searched the ecosystem and found that it exists different tools to mock APIs or to perform requests to them. However we can't find a tool that allows performing HTTP requests that use fixtures and are able to perform specific validation on the responses.

So we started working on Raven!

It relies on PSRs to be easily integrated in any project and is composed of two different parts:

• An HTTP request factory to define the input,
• An executor that'll be responsible to actually validate Requests and Responses.

Raven, isn't it a bird ?

Nope, we use here the human name of the X-Men character Mystique. She's able to transform and adapt to any situation which is that tool goal. We need to adapt to any API to trigger valid requests and analyze responses.

Install it

Using Composer:

To use Raven you might need to also install:

• an HTTP message factory compatible with PSR-17,
• an HTTP client compatible with PSR-18.

Of course you can also write your own. The only constraint is to be compatible with PSRs interfaces.

Usage

Execute Request / Response validation

This library defines its own interfaces for request validation. It comes with an adapter to the league/openapi-psr7-validator package which define a complete validation logic.

Generate requests easily based on configuration

Writing RequestInterface objects manually might not be the simplest way to define your test cases. We created a RequestFactory to help building those objects. It rely on PSR17 HTTP factories.

Here is an example which use the nyholm/psr7.

If the body is given as an array, it will be encoded based on the Content-Type header:

• application/json, no header or unsupported header will be transformed to JSON,
• multipart/form-data, will use http_build_query.

Enrich your request body with resolver

Most of the time having static request bodies will not be powerful enough. We need identifiers and other details extracted from our fixtures. A specific layer can be added around the RequestFactory to resolve body dynamically.

You can combine different Resolver and let the configured body pass through all the methods and be enriched. This library come with a specific Faker resolver to generate data easily with providers (see Faker doc).

You can build your own resolvers using the ValueResolverInterface.

Custom expectations

Validating that the request and the response are respecting the documentation is nice but we might need to add some user defined expectations. Will this request trigger a 401 response ? Is the body containing the correct value ?

Expectation can be built using request definition data. Based on some properties, they will be added dynamically. The expectation collection can be passed to the Executor::execute method.

If one of the expectation fails, the response validation will fail and you'll get the details through a ExpectationFailedException error.

This library come with built in expectations: StatusCode. You can easily build your own using the ResponseExpectationInterface.

License

This package is released under the Apache-2 license.

Contribute

If you wish to contribute to the project, please read the CONTRIBUTING notes.