Let's improve all backends

Whilst continuously working on software for many years, we've come to the conclusion that many teams could improve the quality of their software through better design and black-box testing of backend components.

In our opinion, a backend is broken when …

  1. It becomes harder and harder to maintain and make evolve.
  2. It breaks its clients when released.
  3. It throws 500 errors everytime something is unexpected.
  4. It exposes technical details on errors.
  5. It has recurring performance problems.
  6. It requires looking at the code to discover the services.

Broken backends come with unneccessary costs

  1. The software team is 10 times slower than it could be.
  2. By lack of quality, the backend will eventually be rewritten from scratch.
  3. A deadly security nightmare tends to wait around the corner.
  4. The lack of black-box design is a missed opportunity to think clearly about requirements.

We have observed that testing is not fully undertaken in most teams

  1. Unit tests are often used, but are fined-grained and are sometimes brittle.
  2. Integration testing has unclear boundaries, and most teams skip them.
  3. End-to-end testing is often slow, and focuses on best case scenarios.
  4. Functional black-box testing is ... generally unknown.

Web services offer an opportunity to improve software quality

  1. Web services correspond to high-level software operations and are therefore close to requirements.
  2. Therefore, they offer a great space for clear thinking and stable design.
  3. Being a public API by nature, web services call for robustness & security analysis.
  4. The HTTP protocol they all rely on is standard, rich enough, and technology agnostic.

Based on these observations, we are providing an open-source framework where…

  1. Web services are specified in a simple, human-friendly, yet formal way.
  2. Checking if they meet their specification is as easy as using curl.
  3. PRE/POST contracts provide systematic testing coverage.
  4. A specification can also be turned to documentation, or used for API mocking, code generation, etc.

We think it is complementary to existing alternatives

  1. Our focus is on software quality through specification and testing. We see swagger as complementary, with a focus on documentation and UI tools.
  2. We also think that specifications must be independent from the implementation, not derived from it as with openapi.
  3. We share with cucumber the wish to be human-centric, not machine-centric.
  4. We want to fix an element of vocabulary, by distinguishing a spec from its tests.
  5. We stress the fact that functional testing is not about running best-case scenarios, but about testing the conformity of an implementation to a spec.

We hope you enjoy it, and welcome contributions, ideas, and feedback.