| Approach |
Contract Driven Development (CDD) |
Consumer Driven Contract (CDC), Provider Driven Contract |
| OpenAPI Support |
YES Specmatic leverages OpenAPI Specifications as Executable Contracts |
NO API Contracts are defined with Groovy DSL, YAML, Pact JSON and Spring Rest Docs (There are external tools / libraries which may help with leveraging OpenAPI Specifications) |
| Suitable for Consumer First Development Style (Frontend Before Backend) |
YES Consumer Team can author the API Specification, leverage it as mock / stub and then share it with Provider team as a guideline |
YES CAVEAT – However you have to wait for the contract to be translated into stub on the Provider Side |
| Suitable for Provider First Development Style (Backend Before Frontend, public facing APIs, ec.) |
YES Provider Team can author the API Specification, leverage as tests and then share it with Consumer team to stub the Provider |
YES Provider can author the contract, run it as test, generated stubs and publish it for Consumers |
| Suitable for API First Development Style |
YES Consumer and Provider Teams collaboratively author API Specification and only then being development |
YES CAVEAT – In Spring Cloud Contract, we begin by authoring the API Contract in Contract DSL. However this is not the API Specification which you have to additionally maintain. |
| Parallel Development of Consumer and Provider |
YES This is one of the primary capabilities of Specmatic, to allow teams to independently develop and confidently deploy microservices |
PARTIAL Consumer has to wait for Provider to run the Contract Verification and publish the stubs be it in Consumer Driven Contract or Provider Driven Contract approach |
| Backward Compatibility Verification #NOCODE |
YES This is one of the flagship capabilities in Specmatic. Contract vs Contract comparison, no need to implement the changes in Provider or Consumer Code |
NO It is not possible to identify backward compatiliblity issues withouth implementing / writing code for Provider and Consumer. Backward breaking changes can be identified only by running verifier on provider and stub runner for consumers. |
| API Specifications as Test #NOCODE |
YES Specmatic can generate and run tests, both happy path and boundary conditions, all with just your OpenAPI specifications |
NO Spring Cloud Contract runs its DSL as Test with https://cloud.spring.io/spring-cloud-contract/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html, OpenAPI cannot be run as tests |
| Negative / Boundary Testing |
YES Specmatic now only runs your API Spec as a Contract Tests, it can also verify your application’s behavior for negative inputs (null, empty strings, incorrect data types, etc.) based on the API Specification |
NO |
| API Specifications as Stub #NOCODE |
YES OpenAPI is all you need to run a stub server, no need to define a stub, just the expectation data |
NO Spring Cloud Contract DSL necessary to define the Contract which are then leveraged during verification to generate Stubs |
| Smart Mocks (Stale Stub Detection / Expectation Validation against API Specification) |
YES Immediate Feedback, expectations that are not as per API Spec are immediately rejected with proper error message |
NO Not Applicable. Expectations / response mappings are defined as part of contract itself based on which the stub jars are generated with wiremock mappings jsons. |
| Unfragmented Devex / Minimal learning curve |
YES You just need API Specification of your choice such as OpenAPI and Specmatic – no additional DSLs |
NO To leverage Spring Cloud Contract within the context of a Java and Spring Ecosystem, we only need to know the Contract DSL and understand the verifier and stub runner dependencies, build tools like mvn or gradle and an artifact manager. In polyglot mode the verifier and stub runner are dockerised and contracts / stubs can be stored in source control such as git. Spring Cloud Contract also has Pact integration to extend some of its functionality, however too many tools can add to the complexity. If you are also adopting OpenAPI then that will be completely additional. |
| Can all stakeholders participate / author Contracts / API Specifications |
YES Devs, architects, test engineers, practically anyone who can author an OpenAPI Spec. |
NO Contracts can only be authored by someone who understands one of the supported DSLs |
| Suitable for adoption in Greenfield Projects |
YES Specmatic helps team become productive quickly with Contract Driven Development |
YES |
| Suitable for adoption in Brownfield Projects |
YES Specmatic can immediately provide value on existing projects and helps the team slowly adopt Contract Driven Development |
YES |
| Minimal / No Leakage for Compatibility Issues |
YES Specmatic keeps a tight check on both the Consumer and Provider and immediately provides feedback where they deviate from API Specification thereby preventing compatibility Issues |
YES The feedback cycle can be slower since consumers have to wait for stubs to be generated and shared through artifact manager |
| Low Cost of Maintenance |
YES Since Specmatic is leveraging your API Specifications there is no maintenance overhead. You just need to maintain your Stub / Expectation data. |
NO In comparison to Specmatic which only needs API Specifications, you need to maintain the Contracts which are written in one of the supported DSLs |
| Open Source |
YES License – MIT |
YES |
| Language and Platform Agnostic |
YES Is able to work completely as a standalone executable |
YES Spring Cloud Contract supports YAML DSL and also has Dockerised verifier and stub runner |
| Unlimited Team Size |
YES |
YES |
| Broker Less |
YES Requires no server setup |
YES CAVEAT – Spring Cloud Contract itself is brokerless, however when integrated with Pact, it can work with Pact Broker |
|
Specmatic.io |
Spring Cloud Contract |
