From f6f7115e113a169d52bce11dbe6d64a3912f375d Mon Sep 17 00:00:00 2001 From: digitalvoice-nz <105614349+digitalvoice-nz@users.noreply.github.com> Date: Wed, 30 Oct 2024 22:08:03 +1300 Subject: [PATCH] roadmap and newsletter html update --- 2-day-cdd-workshop/index.html | 2366 +++--- 2-week-signup/index.html | 2586 +++--- 404/index.html | 1166 +-- .../index.html | 1639 ++-- .../index.html | 1697 ++-- .../index.html | 1639 ++-- .../index.html | 1649 ++-- .../index.html | 1649 ++-- .../index.html | 1649 ++-- .../index.html | 1649 ++-- .../index.html | 1657 ++-- .../index.html | 1639 ++-- appearance/india-foss-2024/index.html | 1627 ++-- .../index.html | 1649 ++-- .../index.html | 1639 ++-- .../index.html | 1639 ++-- .../index.html | 1649 ++-- .../index.html | 1639 ++-- .../index.html | 1639 ++-- .../index.html | 1623 ++-- .../index.html | 1649 ++-- .../index.html | 1649 ++-- .../index.html | 1649 ++-- .../index.html | 1649 ++-- appearances/index.html | 2445 +++--- appearances/page/2/index.html | 1862 +++-- .../index.html | 1643 ++-- .../index.html | 1630 ++-- .../index.html | 1630 ++-- .../index.html | 1671 ++-- articles/index.html | 1617 ++-- author/hari/index.html | 1452 ++-- author/jaydeep/index.html | 1248 +-- author/joel/index.html | 1371 +-- author/naresh/index.html | 1330 +-- author/yogesh/index.html | 1248 +-- author/zn2px/index.html | 1443 ++-- cdn-cgi/l/email-protection/index.html | 2 +- .../index.html | 1367 +-- .../index.html | 1421 ++-- .../index.html | 1384 +-- comparisons/index.html | 1314 +-- .../index.html | 1459 ++-- conference/feed/index.xml | 2 +- conference/index.html | 1188 +-- contact-us/index.html | 1232 +-- .../index.html | 1371 +-- .../index.html | 1416 ++-- .../index.html | 1616 ++-- demonstration/index.html | 1571 ++-- .../index.html | 1498 ++-- .../index.html | 1553 ++-- .../index.html | 1465 ++-- demonstration/page/2/index.html | 1327 +-- .../index.html | 1419 ++-- eula/index.html | 1218 +-- .../index.html | 1921 +++-- features/api-resiliency-testing/index.html | 1866 +++-- .../index.html | 1949 ++--- .../index.html | 1925 +++-- .../index.html | 1921 +++-- .../index.html | 1925 +++-- .../index.html | 1963 ++--- .../2/index.html | 1921 +++-- .../index.html | 2005 ++--- .../index.html | 1925 +++-- .../index.html | 1967 ++--- .../2/index.html | 2013 ++--- .../3/index.html | 2005 ++--- .../index.html | 2055 ++--- .../index.html | 1836 ++-- index.html | 7406 +++++++++-------- jobs-at-specmatic/index.html | 1256 +-- .../index.html | 1677 ++-- podcast/index.html | 1191 +-- pricing/index.html | 2236 ++--- roadmap/index.html | 1977 +++-- security-policy/index.html | 1467 ++-- specmatic-updates/index.html | 1554 ++-- specmatic-updates/page/2/index.html | 1552 ++-- specmatic-updates/page/3/index.html | 1435 ++-- spotlight/index.html | 1567 ++-- spotlight/page/2/index.html | 1204 +-- tag/api-coverage-report/index.html | 1193 +-- tag/api-design/index.html | 1191 +-- tag/api-mocking/index.html | 1193 +-- tag/api-testing/feed/index.xml | 2 +- tag/api-testing/index.html | 1188 +-- tag/asyncapi/index.html | 1316 +-- tag/bdct/index.html | 1193 +-- .../index.html | 1193 +-- tag/cdct/index.html | 1193 +-- tag/cdd/index.html | 1193 +-- tag/conference/feed/index.xml | 2 +- tag/conference/index.html | 1188 +-- .../index.html | 1195 +-- tag/consumer-driven-contract/index.html | 1193 +-- tag/continuous-delivery/index.html | 1193 +-- tag/contract-driven-development/index.html | 1562 ++-- tag/contract-testing/index.html | 1562 ++-- tag/database-stubbing/index.html | 1193 +-- tag/demonstration/index.html | 1275 +-- tag/google-pub-sub/index.html | 1193 +-- tag/graphql/index.html | 1193 +-- tag/grpc/index.html | 1234 +-- tag/http/index.html | 1234 +-- tag/integration-testing/index.html | 1234 +-- tag/jdbc/index.html | 1193 +-- tag/jms/index.html | 1193 +-- tag/kafka/index.html | 1234 +-- tag/live-stream/feed/index.xml | 2 +- tag/live-stream/index.html | 1188 +-- tag/microservices/index.html | 1234 +-- tag/openapi/index.html | 1521 ++-- tag/pact/index.html | 1234 +-- tag/pactflow/index.html | 1191 +-- tag/past/feed/index.xml | 2 +- tag/past/index.html | 1188 +-- tag/provider-driven-contract/index.html | 1193 +-- tag/redis/index.html | 1193 +-- tag/resiliency-testing/feed/index.xml | 2 +- tag/resiliency-testing/index.html | 1188 +-- tag/shift-left/feed/index.xml | 2 +- tag/shift-left/index.html | 1188 +-- tag/specmatic/index.html | 1396 ++-- tag/spring-cloud-contract/index.html | 1193 +-- tag/stubbing/index.html | 889 -- tag/upcoming/feed/index.xml | 2 +- tag/upcoming/index.html | 1188 +-- tag/wiremock/index.html | 1234 +-- updates/2023-year-in-review/index.html | 1561 ++-- .../index.html | 1411 ++-- .../index.html | 1452 ++-- .../index.html | 1616 ++-- .../index.html | 1408 ++-- updates/index.html | 1569 ++-- .../index.html | 1438 ++-- .../index.html | 1498 ++-- .../index.html | 1553 ++-- .../index.html | 1465 ++-- updates/media/index.html | 1273 +-- .../index.html | 1393 ++-- .../index.html | 1396 ++-- .../index.html | 1409 ++-- updates/page/2/index.html | 1567 ++-- updates/page/3/index.html | 1450 ++-- .../index.html | 1419 ++-- .../index.html | 1448 ++-- .../index.html | 1344 +-- updates/specmatic-docker-image/index.html | 1347 +-- .../index.html | 1384 +-- .../index.html | 1339 +-- .../index.html | 1440 ++-- .../index.html | 1432 ++-- workshop/feed/index.xml | 2 +- workshop/index.html | 1188 +-- 156 files changed, 119894 insertions(+), 103879 deletions(-) diff --git a/2-day-cdd-workshop/index.html b/2-day-cdd-workshop/index.html index a4cd5823e..46d73a1c8 100644 --- a/2-day-cdd-workshop/index.html +++ b/2-day-cdd-workshop/index.html @@ -3,8 +3,8 @@ - -2-day CDD workshop - Specmatic + + 2-day CDD workshop - Specmatic @@ -15,6 +15,7 @@ + @@ -48,89 +49,68 @@ - + - + - - + + - + - - - + + + - - - + + + - + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + - + @@ -143,10 +123,11 @@ - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-
-
+
+ + +
+
+ +
+
+
-
-
-
-
-
-
-

Beyond Contract Testing -
- Contract Driven Development

-
-
-
-

2-day hands-on workshop

-
-
-
-
-
-
-
-
-

Get started with Contract Driven Development (CDD). This 2-day workshop offers a comprehensive, hands-on introduction to help Developers, Testers, Architects, DevOps and other stakeholders involved in the lifecycle of building complex applications.

-
- -
-
-
-
-
-
-

Workshop overview -

-
-
-
-
-
-

In this Workshop, you will get an in-depth, hands-on introduction to Contract Driven Development (CDD).

+ + +
+
+
+
+
+
+

Beyond Contract Testing +
- Contract Driven Development

+
+
+
+

2-day hands-on workshop

+
+
+
+
+
+
+
+
+

Get started with Contract Driven Development (CDD). This 2-day workshop offers a comprehensive, hands-on introduction to help Developers, Testers, Architects, DevOps and other stakeholders involved in the lifecycle of building complex applications.

+
+ +
+
+
+
+
+
+

Workshop overview +

+
+
+
+
+
+

In this Workshop, you will get an in-depth, hands-on introduction to Contract Driven Development (CDD).

You will learn how to use OpenAPI specifications as executable contracts to achieve parallel development and independent deployment of your microservices & micro-frontends. In this process, you’ll learn how to shift-left the identification of integration issues to achieve quicker time to market.

-

This workshop is hand-crafted to provide Developers, Architects and Quality Engineers the essential techniques to foster a collaborative API Design first culture in their teams.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Leverage API Specifications

-
-
-
-

Create “Executable Contracts” from your API Specs that can be leveraged across various stages of application development. 

-
-
-
-
-
-
-
-
-
-
-
-

Eliminate Integration Issues

-
-
-
-

Integration issues are minimized as the project goes through integration testing, ensuring a smoother and more reliable process.

-
-
-
-
-
-
-
-
-
-
-
-

Achieve Quicker Time to Market

-
-
-
-

Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.

-
-
-
-
-
-
-
-
-
-
-
-

Build Team Collaboration

-
-
-
-

Keep both the client and service teams in sync with a central repo defining  a clear and agreed-upon definition of the API spec.

-
-
-
-
-
-
-
-
-
-
-
-

The Workshop will cover

-
-
-
-
-
-
-
- -
-
-

 Why is integration testing ineffective? How you can leverage contract testing and service virtualization to validate your services conformance to API Specs to identify integration issues early.

-
- -
-
-

How to collaboratively evolve API design and avoid rework.

-
- -
-
-

Via a PR process, ensure backward breaking changes are prevented during API design rather than catching them during integration testing.

-
- -
-
-

Building secure and resilient MicroServices by achieving higher API Coverage with Generative Tests (inspired by Property Based and Mutation Testing).

-
- -
-
-

Cheap, Fast, Reliable Tests in a controlled environment using dependency-emulation & fault-injection.

-
- -
-
-

Instantly generate domain specific test data by using the context in your API spec with GenAI.

-
- -
-
-

Make informed architectural decisions based on deep integration insights.

-
- -
-
-

Run tests locally and as hard-gates in CI pipeline to ensure API Conformance.

-
- -
-
-

Metrics to track CDD adoption and outcomes.

-
-
-
-
-
-
-
-
-
-

Specification Standards

-
-
-
-
-
-ASync API logo
-
-
-
-OpenAPI logo
-
-
-
-
-
-
-
-
-
-

Specification Editor and plugin in

-
-
-
-
-
-Swagger logo
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Programming Languages

-
-
-
-
-
-Java logo
-
-
-
-JavaScript logo
-
-
-
-TypeScript logo
-
-
-
-Python logo
-
-
-
-
-
-
-
-
-
-
-
-

CDD

-
-
-
-
-
-
-
-
-
-
-
-

Linting

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Workshop overview

-
-
-
-

Our hosts

-
-
-
-
-
-
-
-
-
-
-
-
-
-
+

This workshop is hand-crafted to provide Developers, Architects and Quality Engineers the essential techniques to foster a collaborative API Design first culture in their teams.

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Leverage API Specifications

+
+
+
+

Create “Executable Contracts” from your API Specs that can be leveraged across various stages of application development. 

+
+
+
+
+
+
+
+
+
+
+
+

Eliminate Integration Issues

+
+
+
+

Integration issues are minimized as the project goes through integration testing, ensuring a smoother and more reliable process.

+
+
+
+
+
+
+
+
+
+
+
+

Achieve Quicker Time to Market

+
+
+
+

Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.

+
+
+
+
+
+
+
+
+
+
+
+

Build Team Collaboration

+
+
+
+

Keep both the client and service teams in sync with a central repo defining  a clear and agreed-upon definition of the API spec.

+
+
+
+
+
+
+
+
+
+
+
+

The Workshop will cover

+
+
+
+
+
+
+
+ +
+
+

 Why is integration testing ineffective? How you can leverage contract testing and service virtualization to validate your services conformance to API Specs to identify integration issues early.

+
+ +
+
+

How to collaboratively evolve API design and avoid rework.

+
+ +
+
+

Via a PR process, ensure backward breaking changes are prevented during API design rather than catching them during integration testing.

+
+ +
+
+

Building secure and resilient MicroServices by achieving higher API Coverage with Generative Tests (inspired by Property Based and Mutation Testing).

+
+ +
+
+

Cheap, Fast, Reliable Tests in a controlled environment using dependency-emulation & fault-injection.

+
+ +
+
+

Instantly generate domain specific test data by using the context in your API spec with GenAI.

+
+ +
+
+

Make informed architectural decisions based on deep integration insights.

+
+ +
+
+

Run tests locally and as hard-gates in CI pipeline to ensure API Conformance.

+
+ +
+
+

Metrics to track CDD adoption and outcomes.

+
+
+
+
+
+
+
+
+
+

Specification Standards

+
+
+
+
+
+ ASync API logo
+
+
+
+ OpenAPI logo
+
+
+
+
+
+
+
+
+
+

Specification Editor and plugin in

+
+
+
+
+
+ Swagger logo
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Programming Languages

+
+
+
+
+
+ Java logo
+
+
+
+ JavaScript logo
+
+
+
+ TypeScript logo
+
+
+
+ Python logo
+
+
+
+
+
+
+
+
+
+
+
+

CDD

+
+
+
+
+
+
+
+
+
+
+
+

Linting

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Workshop overview

+
+
+
+

Our hosts

+
+
+
+
+
+
+
+
+
+
+
+
+
+
Naresh Jain -
-
-
-

Naresh Jain

-
-
Co-founder
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-

Hari Krishnan

-
-
Co-founder, CTO
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+

Naresh Jain

+
+
Co-founder
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+
+

Hari Krishnan

+
+
Co-founder, CTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Joel Rosario -
-
-
-

Joel Rosario

-
-
Co-founder, Chief Scientist
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-

Jaydeep Kulkarni

-
-
Principal Architect
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

2 Day Overview

-
-
-
-
-
- -
+
+
+
+

Joel Rosario

+
+
Co-founder, Chief Scientist
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+
+

Jaydeep Kulkarni

+
+
Principal Architect
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

2 Day Overview

+
+
+
+
+
+ +
  1. Introductions
  2. Why is microservices architecture not yielding the expected results?
  3. @@ -961,16 +1006,16 @@

    Q & A

-
-
- -
+
+
+ +
  1. Recap of Day 1
  2. @@ -1002,387 +1047,402 @@

    Q & A

-
-
-
-
-
-
-
-
-
-
-

Prerequisites -

-
-
-
-
-
-

This workshop involves hands-on coding labs and group exercises. Bring your laptop.

+
+
+
+
+
+
+
+
+
+
+

Prerequisites +

+
+
+
+
+
+

This workshop involves hands-on coding labs and group exercises. Bring your laptop.

  • The labs will involve basic Java, Python or TS projects.
  • Familiarity with API specifications such as OpenAPI / Swagger, AsyncAPI will be helpful, but not mandatory.
  • Experience building and deploying microservices/micro-frontends will help you appreciate these labs.
  • -
-
-
-
-
-
-
-
-
-
-

-Signup for the 2-day CDD Workshop

-
-
-
-
+
+
+
+
+
+
+
+
+
+
+

+Signup for the 2-day CDD Workshop

+
+
+
+
- -
-
-
-
-
+
+
+
+
+
+
+ + +
+ + + +
-
-
-
-
-
-
-
-
-
- -
-
-
-
+
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + - - + + + + + + + + + + + + + + + + + + @@ -1512,13 +1594,13 @@

- + - + - - + + \ No newline at end of file diff --git a/2-week-signup/index.html b/2-week-signup/index.html index 8984df06a..ce5113170 100644 --- a/2-week-signup/index.html +++ b/2-week-signup/index.html @@ -3,8 +3,8 @@ - -Sign-up for a 2-week POC to kickstart your CDD journey - Specmatic + + Sign-up for a 2-week POC to kickstart your CDD journey - Specmatic @@ -15,6 +15,7 @@ + - + @@ -63,91 +64,70 @@ - + - + - - + + - + - - - + + + - - - + + + - + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + - + - + @@ -160,10 +140,11 @@ - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-
-
+
+ + +
+
+ +
+
+
-
-
-
-
-
-

Discover the benefits of CDD in your organization

-
-
-
-
-
-
-
-

Embrace CDD with confidence. Our 2-week Proof of Concept lets you experience how it fits your business, removes bottlenecks, and accelerates your time to market.

-
- -
-
-
-
-
-
-

Here's what your business will gain

-
-
-
-
-
-

The consultation aims to address any questions while demonstrating the potential of independent development and deployment with CDD to empower your business to achieve faster, more confident, and efficient software development practices.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Increased Pace​

-
-
-
-

Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Enhanced Confidence​

-
-
-
-

Integration issues are minimized as the project goes through integration testing, ensuring a smoother and more reliable process.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Ease of Implementation

-
-
-
-

Our Proof of Concept simplifies the process, allowing you to grasp CDD’s implementation intricacies with ease

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

In-Depth Understanding

-
-
-
-

Our hands-on experience equips your business with insights to navigate the world of Contract Driven Development effectively

-
-
-
-
-
-
-
-
-
-
-
-

What we offer -

-
-
-
-

A proof-of-concept implementation of CDD, at both a code and practice level. Over 2 weeks (10 working days) your team will be guided through the fundamentals of implementing CDD. This includes:

-
-
-
-
-
-
-
- -
-
-

the provider using their OpenAPI Spec and stubbing out provider’s dependencies using OpenAPI or AsyncAPI specs of the dependent services. Also, if required we can stub out Redis, ElasticSearch and database via JDBC.

-
-
-
-
-
-
-
-

Specification Standards

-
-
-
-
-
-ASync API logo
-
-
-
-OpenAPI logo
-
-
-
-
-
-
-
- -
-
-of the provider using the same OpenAPI spec, so that we can component test the consumer.
-
-
-
-
-
-
-
-

Specification Editor and plugin in

-
-
-
-
-
-Swagger logo
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-

with pull/merge request process to enforce necessary backward compatibility checks and linting to ensure high quality specs.

-
-
-
-
-
-
-
-

Programming Languages

-
-
-
-
-
-Java logo
-
-
-
-JavaScript logo
-
-
-
-TypeScript logo
-
-
-
-Python logo
-
-
-
-
-
-
-
- -
-
-

pipelines setup with hard-gates on provider, consumer and central contract repo.

-
-
-
-
-
-
-
-
-
-

CDD

-
-
-
-
-
-
-
-
-
-
-
-

Linting

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

What will you need to get started? -

-
-
-
-
-
-

Definition of Ready: a few components / services / APIs that are representative of your overall technology stack. A few members of your team (part time) who are SMEs on these services to help drive the proof of concept with us.

-
-
-
-
-
-

Criteria for selection of components and services

-
-
-
-
-
-
-
- -
-
-

Select a functionality that cuts across your view.js front-end and Spring Boot backend as a representative functionality of your technology stack.

-
-
-
-
-
- -
-
-

Backend service should have one or more http service dependencies, database dependency, etc. so that we can demonstrate all the concepts clearly.

-
-
-
-
-
- -
-
-

Not overly complex so we can ensure we are able to complete the POC within the stipulated timebox.

-
-
-
-
-
-
-
- -
-
-
-
-
-
-

POC Programme overview

-
-
-
-

Our hosts

-
-
-
-
-
-
-
-
-
-
-
-
+ + +
+
+
+
+
+

Discover the benefits of CDD in your organization

+
+
+
+
+
+
+
+

Embrace CDD with confidence. Our 2-week Proof of Concept lets you experience how it fits your business, removes bottlenecks, and accelerates your time to market.

+
+ +
+
+
+
+
+
+

Here's what your business will gain

+
+
+
+
+
+

The consultation aims to address any questions while demonstrating the potential of independent development and deployment with CDD to empower your business to achieve faster, more confident, and efficient software development practices.

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Increased Pace​

+
+
+
+

Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Enhanced Confidence​

+
+
+
+

Integration issues are minimized as the project goes through integration testing, ensuring a smoother and more reliable process.

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Ease of Implementation

+
+
+
+

Our Proof of Concept simplifies the process, allowing you to grasp CDD’s implementation intricacies with ease

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

In-Depth Understanding

+
+
+
+

Our hands-on experience equips your business with insights to navigate the world of Contract Driven Development effectively

+
+
+
+
+
+
+
+
+
+
+
+

What we offer +

+
+
+
+

A proof-of-concept implementation of CDD, at both a code and practice level. Over 2 weeks (10 working days) your team will be guided through the fundamentals of implementing CDD. This includes:

+
+
+
+
+
+
+
+ +
+
+

the provider using their OpenAPI Spec and stubbing out provider’s dependencies using OpenAPI or AsyncAPI specs of the dependent services. Also, if required we can stub out Redis, ElasticSearch and database via JDBC.

+
+
+
+
+
+
+
+

Specification Standards

+
+
+
+
+
+ ASync API logo
+
+
+
+ OpenAPI logo
+
+
+
+
+
+
+
+ +
+
+ of the provider using the same OpenAPI spec, so that we can component test the consumer.
+
+
+
+
+
+
+
+

Specification Editor and plugin in

+
+
+
+
+
+ Swagger logo
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+

with pull/merge request process to enforce necessary backward compatibility checks and linting to ensure high quality specs.

+
+
+
+
+
+
+
+

Programming Languages

+
+
+
+
+
+ Java logo
+
+
+
+ JavaScript logo
+
+
+
+ TypeScript logo
+
+
+
+ Python logo
+
+
+
+
+
+
+
+ +
+
+

pipelines setup with hard-gates on provider, consumer and central contract repo.

+
+
+
+
+
+
+
+
+
+

CDD

+
+
+
+
+
+
+
+
+
+
+
+

Linting

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

What will you need to get started? +

+
+
+
+
+
+

Definition of Ready: a few components / services / APIs that are representative of your overall technology stack. A few members of your team (part time) who are SMEs on these services to help drive the proof of concept with us.

+
+
+
+
+
+

Criteria for selection of components and services

+
+
+
+
+
+
+
+ +
+
+

Select a functionality that cuts across your view.js front-end and Spring Boot backend as a representative functionality of your technology stack.

+
+
+
+
+
+ +
+
+

Backend service should have one or more http service dependencies, database dependency, etc. so that we can demonstrate all the concepts clearly.

+
+
+
+
+
+ +
+
+

Not overly complex so we can ensure we are able to complete the POC within the stipulated timebox.

+
+
+
+
+
+
+
+ +
+
+
+
+
+
+

POC Programme overview

+
+
+
+

Our hosts

+
+
+
+
+
+
+
+
+
+
+
+
Naresh Jain -
-
-
-

Naresh Jain

-
-
Co-founder
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-

Joel Rosario

-
-
Co-founder, Chief Scientist
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-

Hari Krishnan

-
-
Co-founder, CTO
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-

Jaydeep Kulkarni

-
-
Principal Architect
-
-
-
-
-
-
-
-
-
-
-
-

2 Week Overview

-
-
-
-
-
-
-
- -
    -
  • Get applications running locally with / without mocking dependencies
  • -
  • Complete functional overview and rough architecture diagrams
  • -
  • Get applications running on local machine +
+
+
+

Naresh Jain

+
+
Co-founder
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+
+

Joel Rosario

+
+
Co-founder, Chief Scientist
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+
+

Hari Krishnan

+
+
Co-founder, CTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+
+

Jaydeep Kulkarni

+
+
Principal Architect
+
+
+
+
+
+
+
+
+
+
+
+

2 Week Overview

+
+
+
+
+
+
+
+ +
    +
  • Get applications running locally with / without mocking dependencies
  • +
  • Complete functional overview and rough architecture diagrams
  • +
  • Get applications running on local machine
      -
    • Isolate dependencies – Dockerise, In-memory DB, Queues, etc.
    • -
    • Switch off cross cutting concerns – Authentication, Caching, etc.
    • +
    • Isolate dependencies – Dockerise, In-memory DB, Queues, etc.
    • +
    • Switch off cross cutting concerns – Authentication, Caching, etc.
  • -
  • Automated inventory of routes, routes in API specifications, correctness of API specifications with actuator integration
  • -
  • CI pipelines and version control overview
  • -
  • Record observations, challenges faced
  • +
  • Automated inventory of routes, routes in API specifications, correctness of API specifications with actuator integration
  • +
  • CI pipelines and version control overview
  • +
  • Record observations, challenges faced
-
-
- -
    +
+
+ +
  • Select a route that has API specification / can be generated with Specmatic
  • Provider
    • Run the specification for that route as a test on the Provider on local machine
    • @@ -1020,16 +1065,16 @@

    • Attempt running both of the above test setup on their respective CI pipelines
-
-
- -
    +
+
+ +
  • Create a fresh Git Repository
  • Push the API specification we used above into this repository
  • Reference the same on both Consumer / FE and Provider / BE applications and make sure they are working in CI pipeline also
  • @@ -1050,445 +1095,460 @@

-
-
- -
    +
+
+ +
  • Generate / Record API specifications with Specmatic
  • Review and update the recorded API specifications with respective service owners
  • Strive to reach 80% plus branch coverage independently with Contract Tests alone
-
-
- -
    +
+
+ +
  • Agree on API conventions – naming, response codes, headers, etc.
  • Automate the same with Linter that we setup earlier on central contract repository with custom rules
  • Take stock of API design improvements
-
-
- -
    +
+
+ +
  • Provider – Analyze Specmatic generative test failures and prepare detailed report
  • Consumer – Fault simulation (empty & error state, timeouts, etc.) with Specmatic stub
-
-
- -
    +
+
+ +
  • Analyze asynchronous interaction such as Kafka, JMS, etc.
  • Stub these with Specmatic AsyncAPI support to verify schema compatibility and more
  • Run the AsyncAPI specifications as test where application
-
-
- -
  • Examples: Redis, JDBC, etc. wire compatible stubbing to improve isolation of application in local and CI while running tests
-
-
- -
    +
+
+ +
  • Examples: Redis, JDBC, etc. wire compatible stubbing to improve isolation of application in local and CI while running tests
+
+
+ +
  • Detailed demo with your team members themselves presenting the work they have been able to do
  • Specmatic team sharing their observations and recommendations with detailed action plans
  • Decide on next steps
-
-
-
-
-
-
-
-
-
-
-
-
-

Sign Up for a 2-Week POC Consultation

-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+

Sign Up for a 2-Week POC Consultation

+
+
+
+
- -
-
-
-
-
+
+
+
+
+
+
+ + +
+ + + +
-
-
-
-
-
-
-
-
-
- -
-
-
-
+
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - + + + + + + + + + + + + + + + + + + @@ -1618,13 +1700,13 @@

Sign Up for a 2-Week - + - + - - + + \ No newline at end of file diff --git a/404/index.html b/404/index.html index 6a58896ed..055c6ad98 100644 --- a/404/index.html +++ b/404/index.html @@ -3,8 +3,8 @@ - -404 - Page not found - Specmatic + + 404 - Page not found - Specmatic @@ -15,6 +15,7 @@ + @@ -25,13 +26,13 @@ /*! This file is auto-generated */ !function(i,n){var o,s,e;function c(e){try{var t={supportTests:e,timestamp:(new Date).valueOf()};sessionStorage.setItem(o,JSON.stringify(t))}catch(e){}}function p(e,t,n){e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(t,0,0);var t=new Uint32Array(e.getImageData(0,0,e.canvas.width,e.canvas.height).data),r=(e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(n,0,0),new Uint32Array(e.getImageData(0,0,e.canvas.width,e.canvas.height).data));return t.every(function(e,t){return e===r[t]})}function u(e,t,n){switch(t){case"flag":return n(e,"🏳️‍⚧️","🏳️​⚧️")?!1:!n(e,"🇺🇳","🇺​🇳")&&!n(e,"🏴󠁧󠁢󠁥󠁮󠁧󠁿","🏴​󠁧​󠁢​󠁥​󠁮​󠁧​󠁿");case"emoji":return!n(e,"🐦‍⬛","🐦​⬛")}return!1}function f(e,t,n){var r="undefined"!=typeof WorkerGlobalScope&&self instanceof WorkerGlobalScope?new OffscreenCanvas(300,150):i.createElement("canvas"),a=r.getContext("2d",{willReadFrequently:!0}),o=(a.textBaseline="top",a.font="600 32px Arial",{});return e.forEach(function(e){o[e]=t(a,e,n)}),o}function t(e){var t=i.createElement("script");t.src=e,t.defer=!0,i.head.appendChild(t)}"undefined"!=typeof Promise&&(o="wpEmojiSettingsSupports",s=["flag","emoji"],n.supports={everything:!0,everythingExceptFlag:!0},e=new Promise(function(e){i.addEventListener("DOMContentLoaded",e,{once:!0})}),new Promise(function(t){var n=function(){try{var e=JSON.parse(sessionStorage.getItem(o));if("object"==typeof e&&"number"==typeof e.timestamp&&(new Date).valueOf() - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + @@ -105,7 +108,8 @@ - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + + -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
- -
-

-It looks like the link pointing here was faulty. Maybe try searching?

- +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + - - - + @@ -804,7 +890,7 @@

- - + + \ No newline at end of file diff --git a/appearance/api-design-first-in-practise-an-experience-report/index.html b/appearance/api-design-first-in-practise-an-experience-report/index.html index 4f31f684b..004433cb9 100644 --- a/appearance/api-design-first-in-practise-an-experience-report/index.html +++ b/appearance/api-design-first-in-practise-an-experience-report/index.html @@ -3,8 +3,8 @@ - -API Design First in Practise – An Experience Report - Specmatic + + API Design First in Practise – An Experience Report - Specmatic @@ -15,6 +15,7 @@ + @@ -43,103 +44,103 @@ - + - + - - + + - + - + - - - + + + - - + + - + - + - - - + + + - + - + - + - + - + - + - + - + - + - + - + + + + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - + + + + - + - - + + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-
-
+
+ + +
+
+ +
+
+
-
-
-
-
-
-
-
-
-

Appearances

-
-
-
-
- - -
-
-
-
-
-
-
-
-
-
+ + +
+
+
+
+
+
+
+
+

Appearances

+
+
+
+
+ + +
+
+
+
+
+
+
+
+ + +
+ +
+
-
- -
-
-Hari Krishnan - speaking at ASyncAPI Conference Bangalore 2023 -
-
-
api mocking
-

- -Kafka and JMS Mocking with AsyncAPI using Specmatic -

- -
-
- - - - -More >> - - -
-
-
+
+ + + +
+ +
+ + Hari Krishnan - speaking at ASyncAPI Conference Bangalore 2023 +
+ + +
+
api mocking
+

+ + + + Kafka and JMS Mocking with AsyncAPI using Specmatic + +

+ + + +
+
+ + + + + + + + More >> + + +
+ +
+ +
+
+
-
- -
-
-Screen shot: Contract-driven development: a streamlined approach to software architecture that leverages the power of microservices while solving integration and deployment challenges. -
-
-
Contract Driven Development
-

- -Software Architecture Superstream: Microservices -

- -
-
- - - - -More >> - - -
-
-
+
+ + + +
+ +
+ + Screen shot: Contract-driven development: a streamlined approach to software architecture that leverages the power of microservices while solving integration and deployment challenges. +
+ + +
+
Contract Driven Development
+

+ + + + Software Architecture Superstream: Microservices + +

+ + +
+
+ + + + + + + + + More >> + + +
+ +
+ +
+
+
-
- -
-
- -
-
-
Conference
-

- -Contract-Driven Development-Escape Microservices Integration & Deployment Hell -

- -
-
- - - - -More >> - - -
-
-
+
+ + + +
+ +
+ + +
+ + +
+
Conference
+

+ + + + Contract-Driven Development-Escape Microservices Integration & Deployment Hell + +

+ + +
+
+ + + + + + + + + More >> + + +
+ +
+ +
+
+
-
- -
-
-Contract Driven Development focuses on the use of contracts for guiding software development and ensuring compliance. -
-
-
Conference
-

- -Contract Driven Development – Deploying your Microservices Independently without Integration Testing -

- -
-
- - - - -More >> - - -
-
-
+
+ + + +
+ +
+ + Contract Driven Development focuses on the use of contracts for guiding software development and ensuring compliance. +
+ + +
+
Conference
+

+ + + + Contract Driven Development – Deploying your Microservices Independently without Integration Testing + +

+ + +
+
+ + + + + + + + + More >> + + +
+ +
+ +
+
+
-
- -
-
- -
-
-
Conference
-

- -Contract Driven Development – Deploying your MicroServices independently without integration testing -

- -
-
- - - - -More >> - - -
-
-
+
+ + + +
+ +
+ + +
+ + +
+
Conference
+

+ + + + Contract Driven Development – Deploying your MicroServices independently without integration testing + +

+ + +
+
+ + + + + + + + + More >> + + +
+ +
+ +
+
+
-
- -
-
- -
-
-
Conference
-

- -Turn Your OpenAPI Specifications into Executable Contracts — The Gory Details -

- -
-
- - - - -More >> - - -
-
-
+
+ + + +
+ +
+ + +
+ + +
+
Conference
+

+ + + + Turn Your OpenAPI Specifications into Executable Contracts — The Gory Details + +

+ + +
+
+ + + + + + + + + More >> + + +
+ +
+ +
+
+
-
- -
-
- -
-
-
Conference
-

- -Contract Driven Development – Deploying your MicroServices independently without integration testing -

- -
-
- - - - -More >> - - -
-
-
-
-
-
+
+ + + +
+ +
+ + +
+ + +
+
Conference
+

+ + + + Contract Driven Development – Deploying your MicroServices independently without integration testing + +

+ + +
+
+ + + + + + + + + More >> + + +
+ +
+ +
+
- + +
+ +
+ -
-
-
-
-
-
-
+2 +
+
+
+
+
+
+ + + + + + + + + - - - - -
-
-
-
-
- -
-
-
-
+
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+ + + + + - - - + @@ -1122,7 +1344,7 @@

- + @@ -1133,13 +1355,13 @@

- + - + - - + + \ No newline at end of file diff --git a/article/contract-driven-development-a-real-world-adoption-journey/index.html b/article/contract-driven-development-a-real-world-adoption-journey/index.html index 86a4d18d7..d53661fcb 100644 --- a/article/contract-driven-development-a-real-world-adoption-journey/index.html +++ b/article/contract-driven-development-a-real-world-adoption-journey/index.html @@ -3,8 +3,8 @@ - -Contract-Driven Development – a Real-World Adoption Journey - Specmatic + + Contract-Driven Development – a Real-World Adoption Journey - Specmatic @@ -15,6 +15,7 @@ + @@ -51,100 +52,98 @@ - + - + - - + + - + - + - - - + - - + + - + - + - - - + + + - + - + - + - + - + - + - + - + + + + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + + +
+
+

Author name: Hari Krishnan

+

Hari Krishnan is a Polyglot Full Stack Developer, Architecture Consultant, XP Coach and Trainer, with over 18+ years of experience. -

-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-

Author name: Hari Krishnan

-

Hari Krishnan is a Polyglot Full Stack Developer, Architecture Consultant, XP Coach and Trainer, with over 18+ years of experience. He has worked across multiple tech stacks and application architectures. His domain exposure includes investment banking, network security, telecommunications, logistics and retail. Apart from building products, he has extensive experience in coaching developers, quality specialists, architects, and technology leaders. He has advised several organizations including unicorn startups and large enterprises on their transformation strategy.

-
-
-
-
-
-
+
+
+
+ + + +
+
-
-
-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

-
-
-

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven […]

-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

-
-
+
+
+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+
+
+

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven […]

+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

+
+ +
+
-
+
-
-
-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

-
-
-

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

-
-
+
+
+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

+
+
+

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic Docker Image now available

-
-
-

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

-
-

Specmatic Docker Image now available Read More »

-
-
+
+
+
+

Specmatic Docker Image now available

+
+
+

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

+
+

Specmatic Docker Image now available Read More »

+
+ +
+
-
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+
+ + - - - + @@ -972,7 +1076,7 @@

Categories

- - + + \ No newline at end of file diff --git a/author/jaydeep/index.html b/author/jaydeep/index.html index 517995b5f..05be8f912 100644 --- a/author/jaydeep/index.html +++ b/author/jaydeep/index.html @@ -3,8 +3,8 @@ - -Jaydeep Kulkarni - Specmatic + + Jaydeep Kulkarni - Specmatic @@ -15,6 +15,7 @@ + @@ -35,34 +36,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-

Author name: Jaydeep Kulkarni

-

-
-
-
-
-
-
+
+ + + +
+
+

Author name: Jaydeep Kulkarni

+

+
+
+
+
+ + +
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -869,7 +957,7 @@

Categories

- - + + \ No newline at end of file diff --git a/author/joel/index.html b/author/joel/index.html index 0933dd1de..b1f05a81e 100644 --- a/author/joel/index.html +++ b/author/joel/index.html @@ -3,8 +3,8 @@ - -Joel Rosario - Specmatic + + Joel Rosario - Specmatic @@ -15,6 +15,7 @@ + @@ -33,34 +34,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-

Author name: Joel Rosario

-

-
-
-
-
-
-
+
+ + + +
+
+

Author name: Joel Rosario

+

+
+
+
+
+ + +
+
-
-
-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

-
-
-

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

-
-
+
+
+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

+
+
+

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

API Resiliency and Contract Testing for GraphQL

-
-
-

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

API Resiliency and Contract Testing for GraphQL Read More »

-
-
+
+
+
+

API Resiliency and Contract Testing for GraphQL

+
+
+

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

API Resiliency and Contract Testing for GraphQL Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
+
+
+
Redis stubing - specmatic contact development with contract testing.
+

Redis Stubbing with Specmatic Contract Testing

+
+
+

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

+
+

Redis Stubbing with Specmatic Contract Testing Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -930,7 +1027,7 @@

Categories

- - + + \ No newline at end of file diff --git a/author/naresh/index.html b/author/naresh/index.html index fdf9c639d..95ebfd992 100644 --- a/author/naresh/index.html +++ b/author/naresh/index.html @@ -3,8 +3,8 @@ - -Naresh Jain - Specmatic + + Naresh Jain - Specmatic @@ -15,6 +15,7 @@ + @@ -33,34 +34,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-

Author name: Naresh Jain

-

Naresh Jain is an award-winning, internationally recognized Technology & Product Development Expert. Over the last 15+ years, he has helped many Unicorns and fortune 500 companies like Jio, Google, Amazon, JP Morgan, Hike, Directi, HP, Siemens Medical, GE Energy, Schlumberger, Shell, Dell, EMC, CA Technologies, etc. to streamline their product development. His hands-on approach to coaching teams by focusing on product discovery and engineering excellence is a key differentiator.

-
-
-
-
-
-
+
+ + + +
+
+

Author name: Naresh Jain

+

Naresh Jain is an award-winning, internationally recognized Technology & Product Development Expert. Over the last 15+ years, he has helped many Unicorns and fortune 500 companies like Jio, Google, Amazon, JP Morgan, Hike, Directi, HP, Siemens Medical, GE Energy, Schlumberger, Shell, Dell, EMC, CA Technologies, etc. to streamline their product development. His hands-on approach to coaching teams by focusing on product discovery and engineering excellence is a key differentiator.

+
+
+
+
+ + +
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates […]

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates […]

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

-
-
-

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

-
-
+
+
+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

+
+
+

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

+
+ +
+
-
+
-
-
-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

-
-
-

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

-
-
+
+
+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

+
+
+

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -909,7 +1003,7 @@

Categories

- - + + \ No newline at end of file diff --git a/author/yogesh/index.html b/author/yogesh/index.html index 8bf6349d6..433461cda 100644 --- a/author/yogesh/index.html +++ b/author/yogesh/index.html @@ -3,8 +3,8 @@ - -Yogesh Nikam - Specmatic + + Yogesh Nikam - Specmatic @@ -15,6 +15,7 @@ + @@ -33,34 +34,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-

Author name: Yogesh Nikam

-

-
-
-
-
-
-
+
+ + + +
+
+

Author name: Yogesh Nikam

+

+
+
+
+
+ + +
+
-
-
-
-

Contract Testing using gRPC Specs as Executable Contracts

-
-
-

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, […]

-
-

Contract Testing using gRPC Specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing using gRPC Specs as Executable Contracts

+
+
+

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, […]

+
+

Contract Testing using gRPC Specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -867,7 +955,7 @@

Categories

- - + + \ No newline at end of file diff --git a/author/zn2px/index.html b/author/zn2px/index.html index 730b9be15..3577a6a6a 100644 --- a/author/zn2px/index.html +++ b/author/zn2px/index.html @@ -3,8 +3,8 @@ - -John - Specmatic + + John - Specmatic @@ -15,6 +15,7 @@ + @@ -33,34 +34,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
-

Author name: John

-

-
-
-
-
-
-
+
+ + + +
+
+

Author name: John

+

+
+
+
+
+ + +
+
-
-
-
-

Specmatic Challenge – winners announced!

-
-
-

The Specmatic challenge is over and we are pleased to announce the winners! Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes! You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give […]

-
-

Specmatic Challenge – winners announced! Read More »

-
-
+
+
+
+

Specmatic Challenge – winners announced!

+
+
+

The Specmatic challenge is over and we are pleased to announce the winners! Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes! You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give […]

+
+

Specmatic Challenge – winners announced! Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC

-
-
-

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

-
-
+
+
+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC

+
+
+

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

+
+ +
+
-
+
-
-
-
-

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner

-
-
-
-

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner Read More »

-
-
+
+
+
+

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner

+
+
+
+

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner Read More »

+
+ +
+
-
+
-
-
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
-

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

-
-
+
+
+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+
+
+

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

+
+ +
+
-
+
-
-
-
-

2023 year in review

-
-
-

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come! In this issue:

-
-

2023 year in review Read More »

-
-
+
+
+
+

2023 year in review

+
+
+

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come! In this issue:

+
+

2023 year in review Read More »

+
+ +
+
-
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -967,7 +1070,7 @@

Categories

- - + + \ No newline at end of file diff --git a/cdn-cgi/l/email-protection/index.html b/cdn-cgi/l/email-protection/index.html index 0403ccc43..32ba20fde 100644 --- a/cdn-cgi/l/email-protection/index.html +++ b/cdn-cgi/l/email-protection/index.html @@ -56,7 +56,7 @@

You are unabl + + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-
+ + + +
+ + +
Comparison of Specmatic and Spring Cloud Contract.

Comparison: Specmatic vs Spring Cloud Contract

-
-
+Comparisons, Updates / By + +
+ + +
+ + + +
+ + +

This is the third post in our series where we compare Specmatic with tools that have some overlap in terms of capabilities. In our previous posts we compared Specmatic with Pact and WireMock. In this post we will be looking at Spring Cloud Contract.

+ + +

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+ + +
@@ -400,6 +487,7 @@

Comparison: Specmatic vs Spring Clou
+ @@ -407,7 +495,30 @@

Comparison: Specmatic vs Spring Clou

+ + + + + + + + + + + + + + + + + + + + + + + @@ -574,7 +685,9 @@

Comparison: Specmatic vs Spring Clou

- + + +

@@ -605,73 +718,87 @@

Comparison: Specmatic vs Spring Clou border-top-color: #F1F1F1 !important; }

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
- -
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1161,7 +1298,7 @@

Categories

- - + + \ No newline at end of file diff --git a/comparisons/comparison-specmatic-vs-wiremock/index.html b/comparisons/comparison-specmatic-vs-wiremock/index.html index 23da79510..8b4c36f71 100644 --- a/comparisons/comparison-specmatic-vs-wiremock/index.html +++ b/comparisons/comparison-specmatic-vs-wiremock/index.html @@ -3,8 +3,8 @@ - -Comparison: Specmatic vs WireMock - Specmatic + + Comparison: Specmatic vs WireMock - Specmatic @@ -15,6 +15,7 @@ + @@ -59,76 +60,70 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - - - - - + + + + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+ + + +
+ + +

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
+Comparisons, Demonstration, In the Media, Updates / By + +
+ + +
+ + + +
+ + +
The BEST way to find BUGS in an API | Contract vs Approval Testing – Emily Bache
+ + +

Testing APIs: Specmatic vs TextTest

+ + +

Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing

+ + +

She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service developers and the service consumers. Specmatic is not so much about finding bugs as agreeing expectations about an API.”

+ + +
  • Emily looks into the best ways to find bugs in an API by exploring the use of Contract vs Approval Testing.
  • + + +
  • She takes us through an in-depth comparison of using TextTest and Specmatic to test and expose bugs in the RESTfulBooker API.
  • + + +
  • She explores the concept of contract testing as a means to ensure seamless communication between different teams working on services that communicate via APIs.
  • + + +
  • Observe the power of leveraging API specifications as executable contracts and maintaining them in a central Git repository to ensure that both providers and consumers are working with the correct version of the specification.
  • + + +
  • Check out her video to get a detailed breakdown of the benefits and functionalities of both TextTest and Specmatic in identifying, documenting, and preventing bugs in API development.
+ + +

Key Takeaways from the video

+ + +

1. Exploring API Bugs: Emily demonstrates how RESTfulBooker, intentionally filled with bugs, provides a playground for discovering issues through manual testing and automated tools like Specmatic and Text Test.

+ + +

2. Contract Testing with Specmatic: Emily reveals how Specmatic facilitates contract testing by creating and running tests based on API specifications, ensuring alignment with the expected behaviors. She goes on to explain how this enables teams working on different services to independently verify if their respective services / components comply with the agreed API contract. Emily also discusses how Specmatic is able to use the examples in the OpenAPI specification for generating tests.

+ + +

3. Approval Testing with Text Test: Emily discusses the features and benefits of Text Test, emphasizing its capacity for approval testing by comparing the actual API responses with previously approved outputs. This tool aids in exposing bugs and ensuring proper functionality through meticulous testing and validation.

+ + +

4. Effective Bug Identification: The video sheds light on the significance of thorough bug identification through a combination of manual exploratory testing and automated testing tools, showcasing how both approaches contribute to comprehensive bug detection.

+ + +

Elevating API Testing with Contract Driven Development

+ + +

In the evolving landscape of microservices and API-driven architectures, Contract Driven Development (CDD) emerges as a game-changer. By leveraging API specifications as executable contracts, CDD enables seamless collaboration between service providers and consumers, fostering a robust and reliable API ecosystem.

+ + +

Explore the power of Contract Driven Development in API testing by embracing Specmatic and TextTest. These tools provide indispensable support for developers and testers, ensuring the robustness and reliability of your API infrastructure.

+ + +

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -958,7 +1114,7 @@

Categories

- - + + \ No newline at end of file diff --git a/comparisons/index.html b/comparisons/index.html index 47cc5e749..970677fd7 100644 --- a/comparisons/index.html +++ b/comparisons/index.html @@ -3,8 +3,8 @@ - -Comparisons – Specmatic + + Comparisons – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Comparisons

-
-
+
+ + +
+

Comparisons

+ +
+
-
-
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
-

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service […]

-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

-
-
+
+
+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+
+
+

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service […]

+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -903,7 +995,7 @@

Categories

- - + + \ No newline at end of file diff --git a/comparisons/specmatic-vs-pact-io-and-pactflow-io/index.html b/comparisons/specmatic-vs-pact-io-and-pactflow-io/index.html index ff0df4a8a..6073b7164 100644 --- a/comparisons/specmatic-vs-pact-io-and-pactflow-io/index.html +++ b/comparisons/specmatic-vs-pact-io-and-pactflow-io/index.html @@ -3,8 +3,8 @@ - -Comparison: Specmatic vs Pact.io and Pactflow.io - Specmatic + + Comparison: Specmatic vs Pact.io and Pactflow.io - Specmatic @@ -15,6 +15,7 @@ + @@ -65,36 +66,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-
+ + + +
+ + +
Specmatic vs Pact & Pactflow comparison

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
+Comparisons, Updates / By + +
+ + +
+ + + +
+ + +

Specmatic is unique in its approach towards leveraging API Specification as Executable Contracts. However putting ourselves in the shoes of someone evaluating a process or a tool, it always helps to have detailed comparisons with other tools that may have some similarity. This is the first post in a series where we will be covering techniques and tools that try to address the problem of identifying compatibility issues between microservices early.

+ + +

In this post we will be be looking at Pact which largely popularised Contract Testing. Pact.io or OpenSource Pact is tool that I have personally used and it makes for a great addition to the Dev experience if your development style / process aligns with the workflow of the tool (Consumer Driven Contract Testing). Pactflow.io supports another technique called Bi-Directional Contract Testing (BDCT) which is an interesting approach. Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+ + +
@@ -403,6 +490,7 @@

Comparison: Specmatic vs Pact.io and
+ @@ -411,10 +499,35 @@

Comparison: Specmatic vs Pact.io and

+ + + + + + + + + + + + + + + + + + + + + + + + + @@ -424,6 +537,9 @@

Comparison: Specmatic vs Pact.io and

+ + + - @@ -444,6 +563,9 @@

Comparison: Specmatic vs Pact.io and

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -544,6 +693,9 @@

Comparison: Specmatic vs Pact.io and

+ + + + + + + + + + + + @@ -586,6 +747,9 @@

Comparison: Specmatic vs Pact.io and

+ + + + + + + + + - + + +

@@ -673,82 +845,111 @@

Comparison: Specmatic vs Pact.io and border-bottom-color: #FBFBFB !important; }

+ + +

See also: Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+ + + +
+
-
+ + - -
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -1238,7 +1449,7 @@

Categories

- - + + \ No newline at end of file diff --git a/conference/feed/index.xml b/conference/feed/index.xml index b12971e6e..1b25753ca 100644 --- a/conference/feed/index.xml +++ b/conference/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/conference/index.html b/conference/index.html index bf0bb4f82..404cb27b8 100644 --- a/conference/index.html +++ b/conference/index.html @@ -3,8 +3,8 @@ - -Conference – Specmatic + + Conference – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Conference

-
+
+ + +
+

Conference

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/contact-us/index.html b/contact-us/index.html index 16a84e37e..e18f892c6 100644 --- a/contact-us/index.html +++ b/contact-us/index.html @@ -3,8 +3,8 @@ - -Contact Us - Specmatic + + Contact Us - Specmatic @@ -15,6 +15,7 @@ + - + - - - + + + - - - + + + - + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - - - - - + + + + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

API Resiliency and Contract Testing for GraphQL

+ + + +
+ + +

API Resiliency and Contract Testing for GraphQL

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Transform your GraphQL API specs into executable contracts in seconds

+ + +

Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, thereby making for a one stop solution that enables a seamless DevEx. 

-
+ + + +
+ + + + + +

Getting Started

+ + +

For GraphQL, the setup process is just as straightforward as it is for OpenAPI. All you need are your GraphQL schema files, along with a simple Specmatic configuration, and you’re good to go!

+ + +

Sample GraphQL projects: 

+ + +

https://github.com/znsio/specmatic-order-bff-graphql-java 
https://github.com/znsio/specmatic-order-graphql-ui-react 
https://github.com/znsio/specmatic-order-graphql-consumer-java 

+ + +

Available in Pro Plan and higher

+ + + + + +

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -953,7 +1094,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/contract-testing-google-pub-sub-using-asyncapi-as-executable-contracts/index.html b/demonstration/contract-testing-google-pub-sub-using-asyncapi-as-executable-contracts/index.html index 016074662..7bd97c00f 100644 --- a/demonstration/contract-testing-google-pub-sub-using-asyncapi-as-executable-contracts/index.html +++ b/demonstration/contract-testing-google-pub-sub-using-asyncapi-as-executable-contracts/index.html @@ -3,8 +3,8 @@ - -Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts - Specmatic + + Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts - Specmatic @@ -15,6 +15,7 @@ + @@ -56,36 +57,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+ + + +
+ + +

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts

+ + +

Introduction

+ + +

The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such communication challenge appears when services interact through asynchronous messaging systems like Google Pub/Sub. To ensure reliability and adherence to predefined protocols, contract testing emerges as a crucial strategy. In this blog post, we’ll dive deeper into how Specmatic simplifies contract testing for services dependent on Google Pub/Sub, paving the way for faultless microservices communication through early identification of integration issues.

+ + +

Github Repo: https://github.com/znsio/specmatic-google-pubsub-sample

+ + +

See other demos of Specmatic in action with AsyncAPI:

+ + +

Kafka Mocking with AsyncAPI using Specmatic
JMS Mocking with AsyncAPI using Specmatic

+ + +

Understanding Google Pub/Sub and Contract Testing

+ + +

Google Pub/Sub is a fully-managed real-time messaging service that allows applications to exchange messages effectively. A common scenario entails a service publishing a message to a topic, and another subscribing to that topic to receive the message. The challenge lies in ensuring that both parties agree on the message format—this is where contract testing comes into play.

+ + +

Contract testing verifies interaction between service providers and consumers, confirming each side adheres to the agreed-upon contract. Specmatic, a tool adept at managing contract tests, uses the AsyncAPI specification to automate these tests using the provided schema of messages.

+ + +

AsyncAPI Specifications and Specmatic

+ + +

The AsyncAPI specification acts as a blueprint for your messaging API, defining the message structure, protocols, and channels used for communication. It’s what Specmatic relies on to ensure your Google Pub/Sub messages are both syntactically and functionally correct. Through the use of named examples within the AsyncAPI specification, Specmatic can publish and subscribe to messages, simulating the actions of actual services during the testing process.

+ + +

Utilizing the Google Pub/Sub Emulator

+ + +

Instead of interacting with a live instance of Google Pub/Sub, in this demo we opt for an emulator during testing. This approach accelerates the testing process and removes external dependencies, enabling local and CI pipeline-based executions that provide immediate feedback.

-
+ + + +
Specmatic Contract Test running as part of Github Action
+ + +

Automating with Specmatic

+ + +

In this demonstration of Specmatic’s capabilities, we see how Specmatic operates as an intelligent client for microservices. It sends messages and validates both the presence and correctness of the responses it receives. If requirements aren’t met, Specmatic flags the test as a failure, alerting developers to discrepancies between the service and the contract.

+ + +

The Construction of a Contract Test with Specmatic

+ + +

Constructing contract tests with Specmatic begins by pointing to the AsyncAPI specification within the `specmatic.json` file. Doing so allows Specmatic to generate tests automatically, fostering a seamless integration process.

+ + +

The Value of Specmatic Testing

+ + +

This testing approach facilitated by Specmatic offers a proactive measure for preventing integrations veering off-spec. The demonstration showcases a scenario where deliberately deviating from the AsyncAPI specification causes the contract test to fail. This illustrates Specmatic’s ability to catch errors early, preventing potential bugs from progressing down the deployment pipeline.

+ + +

Specmatic’s Role in Maintaining Contract Integrity

+ + +

Specmatic also ensures consistency across examples used within the AsyncAPI specification, associating messages across publish and subscribe operations via common naming conventions. This feature solidifies the link between message expectations, ensuring that changes in one area of the specification are consistently replicated throughout.

+ + +

Collaborative and Efficient Development

+ + +

Specmatic’s approach of treating AsyncAPI spec as the source of truth for the mutual agreement between microservice teams fosters a collaborative culture where all stakeholder teams can co-create how services interact with each other through asynchronous channels and capture the same as AsyncAPI spec in an iterative manner. This also allows for independent parallel development where teams can confidently build their respective components since Specmatic will ensure contract compatibility of services based on the AsyncAPI spec.

+ + +

Conclusion

+ + +

As services and their communication evolve, Specmatic’s approach to contract testing offers a scalable, efficient, and secure method for ensuring that all messages pass seamlessly between services, keeping the system in harmony. By automating contract tests utilizing the AsyncAPI specification to test Google Pub/Sub integrations, Specmatic allows developers to confidently build and maintain systems that are robust, reliable, and ready to communicate effectively. This exemplifies how automating and aligning software development practices with contract testing can vastly improve the overall software delivery lifecycle.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -969,7 +1155,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html b/demonstration/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html index 9a98362eb..aaf462681 100644 --- a/demonstration/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html +++ b/demonstration/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html @@ -3,8 +3,8 @@ - -Early detection of mismatches between your API specs and app implementation + + Early detection of mismatches between your API specs and app implementation @@ -15,6 +15,7 @@ + @@ -56,36 +57,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+ + + +
+ + +

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

The problem

+ + +

Incomplete API specifications impact feature awareness for consumers and undocumented features cannot be verified against API design standards through linters. Moreover such specifications can neither be leveraged for stubbing / service virtualization nor for contract testing.

+ + +

Key Benefits of the Specmatic API Coverage Report

+ + +

Specmatic’s API coverage report makes it easy to identify and fix mismatches between an OpenAPI specification and an application’s implementation.

+ + +
  1. Identify mismatches between OpenAPI specifications and implementations early in your development cycle.
  2. + + +
  3. Detect paths and methods which are implemented in the application, but not documented in the API specification and vice-versa.
  4. + + +
  5. Fail your CI builds based on API Coverage Report success criteria to prevent mismatches between API specifications and implementations from propagating further.
+ + +

Check out the sample code

+ + +

Sample Java project:
https://github.com/znsio/specmatic-order-api-java

+ + +

Sample Python projects:
https://github.com/znsio/specmatic-order-api-python
https://github.com/znsio/specmatic-order-bff-python
https://github.com/znsio/specmatic-order-bff-python-sanic

+ + +

Sample NodeJS project
https://github.com/znsio/specmatic-order-bff-nodejs

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

-
+ + + +
+ + + + + +

Generating an API coverage report

+ + +

If you have an application which has a route and an OpenAPI specification in which this route is documented, Specmatic can leverage the OpenAPI specification as an executable contract and run contract tests against the application. If the implementation of the route matches the specification, then Specmatic will report the contract test as passed. 

+ + +

What if you document a new path in the specification but fail to actually implement it in the application? Now, any API consumers who use this spec will get a 404 error when they hit this unimplemented path. It could also happen that you add a new route in the application but fail to document it in the specification. The OpenAPI specification is now incomplete and it does not accurately describe the application’s endpoints. An incomplete specification is a huge problem and has serious implications. 

+ + +
  1. The effectiveness of your contract test is compromised. 
  2. + + +
  3. Any API consumers who use this spec will never become aware of the missing path. This will also impact those API consumers who wish to leverage this spec as a stub. You won’t be able to detect API compatibility breakage. 
  4. + + +
  5. You won’t be able to enforce organizational API standards using linters on the undocumented endpoints. 
+ + +

This is exactly the problem that the Specmatic API coverage report solves. Specmatic can detect an application’s endpoints and generate a comprehensive API coverage report. The API coverage report helps us to identify any mismatch between the OpenAPI specification and the application early in the development lifecycle. You can also prevent these issues from propagating any further by failing the CI pipeline build if the API coverage report detects any mismatch.

+ + + + + +

Code walkthrough: API Coverage report in action

+ + +

In this example, we have a Springboot application with a bunch of controllers with routes implemented in them. We also have an OpenAPI specification for this app with all the endpoints described.

-
+ + + +
+ + + + + +

When running a contract test, the key aspect to note is the Endpoints API property, through which Specmatic will determine all the endpoints implemented in the app.

-
+ + + +
+ + + + + +

+ + +

Since this is a Springboot application, we use the mappings endpoint provided by the spring actuator library. When running the example test you’ll see there’s one test which has failed as well in the build.

-
+ + + +
+ + + + + +

API Coverage Report Walkthrough

-
+ + + +
+ + + + + +

The API coverage report lists all the endpoints with their methods and response codes. For every endpoint, it reports the coverage and also indicates if the endpoint is missing in the spec or not implemented in the application. It also reports how many times a particular endpoint was called during the test execution. There are three main issues identified in this example. 

+ + +
  1. The /health endpoint is missing in the spec. 
  2. + + +
  3. The GET method of the products/{id} endpoint is also missing in the spec.
  4. + + +
  5. The products/{id}/inventory endpoint is present in the specification, but not implemented in the app. The corresponding test for this endpoint has also failed. 
+ + +

Below this, you can see that the success criteria for the API coverage report has not been met.

-
+ + + +
+ + + + + +

Let’s dig into this further. The success criteria for the API coverage report is defined in the report configuration section of the specmatic.json file. 

+ + +
  • You can define a minimum overall API coverage required for the build to succeed. 
  • + + +
  • You can define the maximum number of endpoints that can be found missing in the specification. 
-
+ + + +
+ + + + + +

Specmatic can be configured to enforce the above success criteria and fail the build if either any of them are not met. 

+ + +

With this in mind, let’s revisit the API coverage report and try to fix these issues.

+ + +

First, let us implement the missing endpoint which is present in the specification, but not available in the app.

+ + +

After implementing the missing endpoint, when we re-run the test you’ll see that where it previously failed it is now passing.

-
+ + + +
+ + + + + +

But the build will still fail because the success criteria of the API coverage report have not been met. Total API coverage is still 79%, whereas the required threshold is set to 100%. Also, there are two endpoints in the application that have not been documented in the specification and the maximum threshold for missing endpoints in the specification is zero.

-
+ + + +
+ + + + + +

Let us add the missing GET method for the product/{id} endpoint to the specification and try running the test again. Please note that apart from adding the GET method, we also need to include examples for the same, without which Specmatic would still consider it as missing in spec.

+ + +

In the coverage report, you’ll now see that this GET method is reported as covered.

-
+ + + +
+ + + + + +

The build fails again because the success criteria still hasn’t been met. The API coverage now is 83%, less than the threshold of 100%, and there is still one missing endpoint in the specification, and that’s the health endpoint. 

+ + +

It’s possible you want to exclude certain monitoring endpoints like health and heartbeat from the coverage report. This can be done in the report configuration section of Specmatic’s config file by adding the URL in the excluded endpoints array.

-
+ + + +
+ + + + + +

Running the test again you’ll see all tests are passing. The API coverage is 100% and there are no missing endpoints in the specification. The success criteria of the API coverage report have been met, and the build passes as well. 

-
+ + + +
+ + + + + +

This should give you an idea of what a powerful tool the API coverage report is and how it helps ensure that your OpenAPI specifications accurately describe your application. 

+ + +

The OpenAPI coverage report is available now for:

+ + +
  • Java Springboot
  • + + +
  • Node.js
  • + + +
  • Python
+ + + + + +

Continuous Integration Build

+ + +

As mentioned earlier, we can fail the CI builds based on API coverage success criteria. Here is an example Github action that has failed on a pull request pre-merge check because an endpoint was added to the implementation without updating the API specification.

-
-
+ + + +
+ + + +
+ + + + + +

Check out the sample code

+ + +

Sample Java project:
https://github.com/znsio/specmatic-order-api-java

+ + +

Sample Python projects:
https://github.com/znsio/specmatic-order-api-python
https://github.com/znsio/specmatic-order-bff-python
https://github.com/znsio/specmatic-order-bff-python-sanic

+ + +

Sample NodeJS project
https://github.com/znsio/specmatic-order-bff-nodejs

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1036,7 +1396,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/index.html b/demonstration/index.html index ef3bbe7f7..8ead0a52c 100644 --- a/demonstration/index.html +++ b/demonstration/index.html @@ -3,8 +3,8 @@ - -Demonstration – Specmatic + + Demonstration – Specmatic @@ -15,6 +15,7 @@ + @@ -35,34 +36,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Demonstration

-
-
+
+ + +
+

Demonstration

+ +
+
-
-
-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

-
-
-

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

-
-
+
+
+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

+
+
+

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

-
-
-

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven

-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

-
-
+
+
+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+
+
+

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven

+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

-
-
-

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

-
-
+
+
+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

+
+
+

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

+
+ +
+
-
+
-
-
-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

-
-
-

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

-
-
+
+
+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

+
+
+

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

+
+ +
+
-
+
-
-
-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

-
-
-

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

-
-
+
+
+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

+
+
+

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

+
+ +
+
-
+
-
-
-
-

API Resiliency and Contract Testing for GraphQL

-
-
-

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

API Resiliency and Contract Testing for GraphQL Read More »

-
-
+
+
+
+

API Resiliency and Contract Testing for GraphQL

+
+
+

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

API Resiliency and Contract Testing for GraphQL Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
-

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

-
-
+
+
+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+
+
+

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -1041,7 +1150,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/jdbc-stubbing-with-specmatic-contract-testing/index.html b/demonstration/jdbc-stubbing-with-specmatic-contract-testing/index.html index 514f07b8d..548c04b22 100644 --- a/demonstration/jdbc-stubbing-with-specmatic-contract-testing/index.html +++ b/demonstration/jdbc-stubbing-with-specmatic-contract-testing/index.html @@ -3,8 +3,8 @@ - -Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing - Specmatic + + Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing - Specmatic @@ -15,6 +15,7 @@ + @@ -57,36 +58,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+ + + +
+ + +

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Context

+ + +

To test our applications effectively on our local machines and in lower environments such as CI pipelines, we often need to isolate them from their database dependencies to make sure that the test environment is simple to set up and our tests themselves are quick to run. A few popular options that come to mind to achieve the same include in-memory databases and containerised databases. However, there are limitations to each of these approaches.

+ + +
  1. In-memory DBs – They are database simulators and usually cannot handle syntax and data types that may be proprietary / vendor specific to your database. Legacy applications with stored procedures may be even harder to deal with.
  2. + + +
  3. Containerised DBs – They are real databases and thereby also involve significant effort initially to achieve parity with your production database in terms of schema and data setup (Especially in legacy applications which lack automated DB deployment mechanisms).
+ + +

To overcome these limitations we need a “Database Stub”.

+ + +

Solution

+ + +

Specmatic JDBC Stub is a completely wire-compatible setup that has none of the above limitations. It is able to seamlessly stub a JDBC datasource because of which your application thinks it is talking to a real database. This helps in creating a realistic test environment that can be quickly spun up in-memory.

+ + +

Key features

+ + +
  1. Eliminate Database Dependency: JDBC stubs allow us to isolate APIs from their database dependencies, enabling us to test without the need for a complex DB setup. By switching out the data source with a Specmatic JDBC stub, the API can communicate with the stub instead of the actual database.
  2. + + +
  3. Define / Record and Replay Expectations: With Specmatic JDBC stub, we can set expectations for queries and their responses. These expectations can be written by hand or recorded based on actual interactions between the API and a real database. This allows you to verify that your application is only interacting with the database as intended by you.
  4. + + +
  5. Stub vendor specific SQL syntax – Since Specmatic JDBC stub operates at the level of abstraction of a DataSource, you can effectively stub all types of interactions including stored procedure calls.
  6. + + +
  7. Blazing Fast In-memory Setup – Super charge your tests (component, contract and API tests and more) with Specmatic’s fast in-memory JDBC stubbing capability that speeds up your overall test execution time thereby making for a great Developer Experience.
+ + +

By leveraging Specmatic JDBC stubs, we can effectively test APIs, reduce dependencies, and ensure the reliability and integrity of our applications.

+ + +

Check out the sample code

+ + +

Sample project: Manual configuration
Sample project: Spring auto-configuration

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + +

+ + +
Jdbc stubing production mode jdbc stubing test mode Redis Stubbing with Specmatic Contract Testing.
+ + + + + +

Benefits of Specmatic JDBC Stub: Replacing Real Data Sources & Enhancing the Testing Process

+ + +

At the core of the testing process lies the ability to isolate the application from its database dependency. Specmatic JDBC stub achieves this by replacing the real data source with a Specmatic data source. By doing so, the API under test communicates with the Specmatic JDBC stub instead of the actual database. This allows developers to run different types of tests without the hassle of depending on a complex database setup. The Specmatic JDBC stub acts as a drop in replacement for  the database in your test environments, ensuring smooth communication and accurate test results.

+ + +

Setting Expectations with Specmatic JDBC Stub for Contract-Based API Testing

+ + +

To effectively use Specmatic JDBC stub, the first step is to set expectations with the stub regarding the queries that it can expect and the corresponding data it needs to respond with. These expectations can be manually written or recorded based on actual interactions between the API and a real database. Once the expectations are set, the real database is no longer required in the testing setup.

+ + + + + +

Code walkthrough: Specmatic JDBC Stub for Testing

+ + +

Let’s delve into a concrete example to illustrate the power of the Specmatic JDBC stub. Consider an application that provides a wrapper for managing product entities. In its production configuration, it relies on a real database for data storage.

+ + +
A screen shot showcasing Specmatic's JDBC stubbing capabilities to liberate from database dependencies.
+ + + + + +

However, for testing purposes, we want to isolate the application from the actual database. By disabling the data source auto-configuration, the application loses its ability to communicate with the real database.

+ + +
A code editor with JDBC Stubbing capabilities.
+ + + + + +
Using Specmatic for JDBC Stubbing to break database dependencies in a web browser screenshot.
+ + + + + +

Instead, we configure the Specmatic JDBC stub as the data source for testing. This is achieved by adding the Specmatic JDBC dependency and setting up a bean for the data source, specifying the port and directory where the expectations are stored.

+ + +
Leveraging Specmatic for JDBC Stubbing in a code editor screen of Adobe Acrobat.
+ + + + + +

Seamless Contract Testing with the Specmatic JDBC Stub and OpenAPI Specification

+ + +

With the Specmatic JDBC stub in place, we can now run contract tests based on the OpenAPI specification of the API. These tests make HTTP requests to the application, which in turn communicates with the Specmatic data source.

+ + +

The data source responds with the predefined data that was set up as part of the expectations.

+ + +
Leveraging Specmatic for JDBC Stubbing in a code editor screenshot.
+ + + + + +

When Specmatic JDBC stub receives queries that it is not expecting, it throws errors to indicate the same thereby giving us feedback when our application code is making any additional calls to the database.

+ + +
A screenshot of Specmatic, a Java script editor for breaking database dependencies by leveraging JDBC stubbing.
+ + + + + +

From the application’s perspective, it appears as if it is interacting with the real database. The application processes the data and returns it to the Specmatic contract test, which then validates if the response conforms to the schema described in the OpenAPI specification.

+ + +

This seamless integration allows developers to confidently test their applications while eliminating the need for an actual database.

+ + +

The Benefits of Utilising Specmatic JDBC Stub for Testing Applications with Database Dependencies

+ + +

In conclusion, Specmatic JDBC stub provides a powerful solution for testing applications with database dependencies. By replacing the real data source with the Specmatic data source, developers can easily isolate their applications from complex database setups in their test environments and perform comprehensive tests including API, contract tests and more. For example, with Specmatic’s ability to generate contracts from OpenAPI specifications (API specifications as contract tests), developers can verify the correctness of their APIs without the need for an actual database instance.

+ + +

By leveraging Specmatic JDBC stub, developers can streamline the testing process, increase test coverage, and ensure the reliability and stability of their applications.

+ + +

+ + +

Sample project: Manual configuration
Sample project: Spring auto-configuration

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Contact us to join the private beta.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1007,7 +1277,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/jms-mocking-with-asyncapi-using-specmatic/index.html b/demonstration/jms-mocking-with-asyncapi-using-specmatic/index.html index b920582b3..06e5e98b5 100644 --- a/demonstration/jms-mocking-with-asyncapi-using-specmatic/index.html +++ b/demonstration/jms-mocking-with-asyncapi-using-specmatic/index.html @@ -3,8 +3,8 @@ - -JMS Mocking with AsyncAPI using Specmatic - Specmatic + + JMS Mocking with AsyncAPI using Specmatic - Specmatic @@ -15,6 +15,7 @@ + @@ -57,36 +58,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

JMS Mocking with AsyncAPI using Specmatic

+ + + +
+ + +

JMS Mocking with AsyncAPI using Specmatic

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Key features

+ + +
  1. Mocks a real JMS server so that clients can communicate with it seamlessly.
  2. + + +
  3. Validates the messages that it receives against the schema defined in the AsyncAPI specification.
  4. + + +
  5. Provides the ability to set and verify expectations on it.
+ + + + + +

Check out the sample code

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-jms
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + + + + +

Overview – how Specmatic can be used to mock JMS using AsyncAPI

-
+ + + +
+ + + + + +

Let’s take the example of a consumer which makes a request to an application. The request is received by the controller, which in turn invokes the service layer. The service layer fetches data from a domain service or an HTTP dependency, and then drops the message on to a JMS queue – something like Active MQ. Finally, the service layer responds back to the controller, which in turn responds back to the consumer. Now, to test this application in isolation, we take an AsyncAPI specification which describes the JMS queue and the schema of the messages that it is expected to receive. And we mock it out using Specmatic’s JMS mock. With the JMS mock now in place, we can run contract tests against the application. 

+ + +

First, we set expectations on the JMS mock, describing the messages it is expected to receive. Then, we also set expectations on Specmatic’s HTTP stub, which uses the OpenAPI specification for the application’s HTTP dependency or the domain service. If you want to learn more about contract tests and how to stub out HTTP dependencies using OpenAPI specifications and Specmatic, check out this video.

+ + +

Next, Specmatic uses the application’s OpenAPI specification to run contract tests against it. Every contract test results in a request being sent to the application, which is received by the controller. The controller invokes the service layer, which in turn fetches the data now from Specmatic’s HTTP stub. And then drops the message on to Specmatic’s JMS mock. When the JMS mock receives the message, it validates the message against the schema defined in the AsyncAPI specification. If the message does not match the schema, then it will fail the test. The JMS mock has an in-memory active MQ broker, so the service layer can communicate with it quite seamlessly just like it would with a real-time JMS queue in production.

+ + +

Finally, the service layer responds back to the controller, which in turn responds back to the contract test. When all contract tests are executed, Specmatic calls the JMS mock to validate the messages that it has received.

+ + + + + +

Code walkthrough: Contract Test demonstrating Specmatic JMS mock in action

+ + +

We have a service layer which fetches data from a domain service or an HTTP dependency and then sends messages to a JMS queue.

-
+ + + +
+ + + + + +

The specmatic.json file of this application provides an AsyncAPI specification for the application’s JMS dependency, an OpenAPI specification for the application’s HTTP dependency for the domain service, and also an OpenAPI specification for the application itself, which Specmatic will use to run contract tests.

-
+ + + +
+ + + + + +

Since we are talking about JMS, let’s have a look at the AsyncAPI specification. We have defined a queue named product queries, and this is the schema of the messages that it is expected to receive. For the contract tests, we first set the host and the port which Specmatic will use to run contract tests against the application.

-
+ + + +
+ + + + + +

Then we specify an endpoints API which Specmatic will use to determine the routes exposed by this application. For this, we use the mappings endpoint provided by the Spring Actuator library.

-
+ + + +
+ + + + + +

If we look at the controllers in this application, we can see that there are two routes defined. Specmatic will use this information to generate a coverage summary report, which we shall see shortly.

-
+ + + +
+ + +

+ + +

Back to the contract tests, we next create the JMS mock and set expectations on it. What we are saying here is that we expect that a queue named product-queries will receive three messages on it.

-
+ + + +
+ + + + + +

Next, we create the HTTP stub, set expectations on it, start the application, and run the tests. After all contract tests are executed, we check if the expectations set on the JMS mock are met. To do this, we call the verifyExpectations method. The verify expectations method will assert that the product-queries queue received exactly three messages, and all three messages match the schema defined in the specification. If either of these conditions are not met, the verifyExpectations method will report errors.

-
+ + + +
+ + + + + +

With this background, let’s run the contract tests. We can see all contract tests have passed.

-
+ + + +
+ + + + + +

Now, looking at the Coverage Summary Report we can see again there are two routes defined in the application. But since in the OpenAPI specification of this application, there is only one route defined, we see only one route is reported with state is covered, one while the other one is reported with state is missed.

-
+ + + +
+ + + + + +

Let’s now look at the API tests.

+ + + + + +

Code walkthrough: API Test demonstrating Specmatic JMS mock in action

+ + +

In this class, we have tests to validate each of the routes defined in the application. This is the test in which we expect messages on the JMS mock. So we start by setting expectations on the JMS mock similar to what we saw in the contract test. We expect three messages on the productQueries queue.

-
+ + + +
+ + + + + +

We then set expectations on the HTTP stub. We invoke the API or route. We validate the response, and then we assert if the expectations set on the JMS mock are met by calling the verifyExpectations method similar to the way we did it in the contract test.

-
+ + + +
+ + + + + +

We also further assert the actual message received by JMS mock by calling the object message received on channel method as described here.

-
+ + + +
+ + + + + +

With all this setup, we run the API tests. Here we can see all the API tests have passed as well.

-
+ + + +
+ + + + + +


The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+ + +

Available in the Pro plan or higher

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-jms
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1008,7 +1305,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/kafka-mocking-with-asyncapi-using-specmatic/index.html b/demonstration/kafka-mocking-with-asyncapi-using-specmatic/index.html index 0846c20df..4de9e391a 100644 --- a/demonstration/kafka-mocking-with-asyncapi-using-specmatic/index.html +++ b/demonstration/kafka-mocking-with-asyncapi-using-specmatic/index.html @@ -3,8 +3,8 @@ - -Kafka Mocking with AsyncAPI using Specmatic - Specmatic + + Kafka Mocking with AsyncAPI using Specmatic - Specmatic @@ -15,6 +15,7 @@ + @@ -54,36 +55,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Kafka Mocking with AsyncAPI using Specmatic

+ + + +
+ + +

Kafka Mocking with AsyncAPI using Specmatic

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Check out the sample code

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-nodejs
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + +

In our previous post, we looked at how we can stub out redis with Specmatic so that we can test our application independent of its dependency on Redis. In this post we will be looking at mocking Kafka with Specmatic by leveraging AsyncAPI specification.

+ + + + + +

Overview – how Specmatic can be used to mock Kafka using AsyncAPI

-
+ + + +
+ + + + + +

Let’s take the example of an HTTP consumer that sends a request to an API application. The request is received by the controller, which invokes a service layer that fetches data from an HTTP API dependency, and then drops a message onto a Kafka topic. The service layer returns a response to the controller, which in turn returns a response to the consumer.

+ + +

To test this application independently, we need to isolate it from its http and Kafka dependencies. Specmatic can stub Http API dependencies by leveraging their OpenAPI specifications. For asynchronous interactions such as those over Kafka, Specmatic can leverage AsyncAPI specifications.

+ + +

To isolate our application / system under test from its Kafka dependency, let us take an  AsyncAPI specification that defines the format for messages on the Kafka topic and mock it out using Specmatic’s Kafka mock.

+ + +
Overview – how Specmatic can be used to mock Kafk type: string YAML
+ + + + + +

Let’s say we also use Specmatic to run contract tests against the application. First, we must set expectations on  the Kafka mock about messages that it will receive. Then we must set expectations (response mappings) on Specmatic HTTP stub that is leveraging the OpenAPI specification of the HTTP dependency (Domain Service in the diagram above). You can learn more about contract testing and HTTP stubbing with Specmatic in other videos. Finally, Specmatic uses the application’s OpenAPI specification to run contract tests against it.

+ + +

Each contract test sends a request to the application which is received by the controller which in turn invokes the service layer. The service layer fetches data from the HTTP service stub and drops a message onto the topic on the Kafka mock. The Kafka mock uses an in memory Kafka broker, so the service layer sends messages to it seamlessly. Because of this, to the application it will be exactly like sending messages to a real Kafka broker in production. The service layer responds to the controller, which in turn responds to the contract test. After the contract tests have run, Specmatic asks the Kafka mock to verify the messages that it received. Let’s see this in an actual example.

+ + + + + +

Code walkthrough: Contract Test demonstrating Specmatic Kafka mock in action

+ + +

Here’s an application that fetches data from an HTTP API and writes a message to a Kafka broker.

-
+ + + +
+ + + + + +

Here is a specmatic.json, in which we provide the path to AsyncAPI specification file for mocking out the Kafka dependency, the OpenAPI specification for stubbing out the HTTP dependency which the application needs, and the OpenAPI specification of the application itself which Specmatic will use to run contract tests.

-
+ + + +
+ + + + + +

Now, let’s run the contract tests.

-
+ + + +
+ + + + + +

In the API coverage summary for the above test, we have a contract test for one of the APIs, but not for the other, and so it’s marked as missed.

+ + +

Let’s look at how the Kafka expectations are being set and verified.

-
+ + + +
+ + + + + +

After starting the Specmatic Kafka mock, we set an expectation that it would receive a single message on the “product queries” topic. When the test runs, any messages received on this topic are validated against the product queries schema in the AsyncAPI specification. Finally, we verify the kafka mock. This checks if, as per expectations, the mock has received a single message at the product queries topic, and if that message adhered to the AsyncAPI specification. If either of these conditions are not met, or say if a topic that has not been captured in the AsyncAPI specification received a message, the verification fails. The message verification process lets the test keep a tight rein on all Kafka messages sent by the application.

+ + +

Code walkthrough: API Test demonstrating Specmatic Kafka mock in action

+ + +

The setup for API tests is on similar lines to the Specmatic contract tests. Let’s take a quick look at the test set up.

-
+ + + +
+ + + + + +

Like with the contract tests, we start a Kafka mock, and then we set an expectation that a single message is expected on the product queries topic. Then in the test, we verify that the required message has indeed been received, and this line will verify that only one message on the product queries topic has been received as defined by the expectation set earlier on.

+ + +

Since the Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-nodejs
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1093,7 +1318,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/page/2/index.html b/demonstration/page/2/index.html index aac5988b2..2d94222b3 100644 --- a/demonstration/page/2/index.html +++ b/demonstration/page/2/index.html @@ -3,8 +3,8 @@ - -Demonstration – Page 2 – Specmatic + + Demonstration – Page 2 – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Demonstration

-
-
+
+ + +
+

Demonstration

+ +
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
+
+
+
Redis stubing - specmatic contact development with contract testing.
+

Redis Stubbing with Specmatic Contract Testing

+
+
+

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

+
+

Redis Stubbing with Specmatic Contract Testing Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -915,7 +1006,7 @@

Categories

- - + + \ No newline at end of file diff --git a/demonstration/redis-stubbing-with-specmatic-contract-testing/index.html b/demonstration/redis-stubbing-with-specmatic-contract-testing/index.html index 5e7f935ba..90eceb8a3 100644 --- a/demonstration/redis-stubbing-with-specmatic-contract-testing/index.html +++ b/demonstration/redis-stubbing-with-specmatic-contract-testing/index.html @@ -3,8 +3,8 @@ - -Redis Stubbing with Specmatic Contract Testing - Specmatic + + Redis Stubbing with Specmatic Contract Testing - Specmatic @@ -15,6 +15,7 @@ + @@ -54,36 +55,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Redis Stubbing with Specmatic Contract Testing

+ + + +
+ + +

Redis Stubbing with Specmatic Contract Testing

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Check out the sample code

+ + +

Sample files: https://github.com/znsio/specmatic-redis-sample
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + + + + +

Transcript

+ + +

Overview – how Specmatic can be used to stub out Redis

+ + +

A typical HTTP consumer would send an HTTP request to an API where it is received by a controller. Let’s say the controller needs to fetch some data using a service object, and let’s say the service object looks up the data in an instance of Redis. Redis responds with the data, the service object returns it to the controller, and the controller uses the data to formulate a response to the consumer. This is how it works in production. But in test mode, things might be a little different. Let’s say there’s an OpenAPI specification for the API, and we feed it to Specmatic to run contract tests against the API. Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub. The Redis stub responds and the service class understands it. None the wiser that it isn’t an actual instance of Redis.

+ + +

The stub is wire compatible, so no changes are needed in the service class for this to work.

-
+ + + +
+ + + + + +

Specmatic Redis stub in action

+ + +

Let’s take a sample API that needs Redis to function. Here’s the StoreController class using the StoreService object to look up some data.

-
+ + + +
+ + + + + +

The StoreService object, in turn, looks up Redis. We’re now going to run contract tests against this API using its API specification. The contract tests will be generated from the specification by Specmatic. The specification from which the contract tests are generated is in a central Git repository.

+ + +

You can learn more about how Specmatic runs contract tests in a previous video.

+ + +

Now, let’s run the contract tests. It won’t take long. Let’s take a look at the first test. Let’s scroll down a little in the logs. We can see a test here for a GET API to fetch the description of a store with ID 1. We get this response.

-
+ + + +
+ + + + + +

This description was provided by a Redis lookup. If we scroll up a little, we can see the log from the Redis tab showing the request that it received and the response that it returned. The stub itself is wire compatible. So the same code that talks to an actual Redis instance will talk to Specmatic’s Redis stub. But how did the stub know to return this response? Let’s dig a little deeper. Just after starting up the stubbed Redis instance, we set expectations on it.

-
+ + + +
+ + + + + +

For example, when it receives a GET operation with description hyphen 1, it should return this response, and so on. In fact, we can do dependency fault injection here. The Redis stub can simulate Redis errors to test that our application responds appropriately. The Redis stub setup is self contained within the test. The stub itself starts up within a millisecond. And this is all great because this test can easily run now in CI or even just locally on the laptop.

+ + +

+ + +

Available in the Pro plan or higher

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -965,7 +1148,7 @@

Categories

- - + + \ No newline at end of file diff --git a/eula/index.html b/eula/index.html index 6533fc150..e14aa3160 100644 --- a/eula/index.html +++ b/eula/index.html @@ -3,8 +3,8 @@ - -End User License Agreement - Specmatic + + End User License Agreement - Specmatic @@ -15,6 +15,7 @@ + @@ -47,74 +48,71 @@ - + - + - - + + - + - - - + + + - - - + + + - + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - + - + - - - - - + + + + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- - -
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -839,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/pricing/index.html b/pricing/index.html index 4cd91ace1..533bcaa7d 100644 --- a/pricing/index.html +++ b/pricing/index.html @@ -3,8 +3,8 @@ - -Pricing - Specmatic + + Pricing - Specmatic @@ -15,6 +15,7 @@ + @@ -47,71 +48,65 @@ - + - + - - + + - + - - - + + + - - - + + + - + - + - + - + - + - - - - - - - + + + + - + - - - - - - - + + + + + + + - + - + - - - - - - - - + + + + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
- -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+
+
+
-
-
-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

-
-
-

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

-
-
+
+
+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

+
+
+

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

-
-
-

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven

-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

-
-
+
+
+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+
+
+

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven

+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

-
-
-

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

-
-
+
+
+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

+
+
+

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

+
+ +
+
-
+
-
-
-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

-
-
-

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

-
-
+
+
+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

+
+
+

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

+
+ +
+
-
+
-
-
-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

-
-
-

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

-
-
+
+
+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

+
+
+

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic Challenge – winners announced!

-
-
-

The Specmatic challenge is over and we are pleased to announce the winners! Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes! You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give

-
-

Specmatic Challenge – winners announced! Read More »

-
-
+
+
+
+

Specmatic Challenge – winners announced!

+
+
+

The Specmatic challenge is over and we are pleased to announce the winners! Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes! You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give

+
+

Specmatic Challenge – winners announced! Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing using gRPC Specs as Executable Contracts

-
-
-

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

Contract Testing using gRPC Specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing using gRPC Specs as Executable Contracts

+
+
+

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

Contract Testing using gRPC Specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC

-
-
-

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

-
-
+
+
+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC

+
+
+

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

+
+ +
+
-
+
-
-
-
-

API Resiliency and Contract Testing for GraphQL

-
-
-

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

API Resiliency and Contract Testing for GraphQL Read More »

-
-
+
+
+
+

API Resiliency and Contract Testing for GraphQL

+
+
+

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

API Resiliency and Contract Testing for GraphQL Read More »

+
+ +
+
-
-
-
-
+
+ -
+ +
+
- -
- - -
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1039,7 +1137,7 @@

Categories

- - + + \ No newline at end of file diff --git a/specmatic-updates/page/2/index.html b/specmatic-updates/page/2/index.html index 4972f9478..e1549827e 100644 --- a/specmatic-updates/page/2/index.html +++ b/specmatic-updates/page/2/index.html @@ -3,8 +3,8 @@ - -Specmatic Updates – Page 2 – Specmatic + + Specmatic Updates – Page 2 – Specmatic @@ -15,6 +15,7 @@ + @@ -36,34 +37,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - - + + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
- -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+
+
+
-
-
-
-

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner

-
-
-
-

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner Read More »

-
-
+
+
+
+

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner

+
+
+
+

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
-

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

-
-
+
+
+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+
+
+

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic Docker Image now available

-
-
-

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

-
-

Specmatic Docker Image now available Read More »

-
-
+
+
+
+

Specmatic Docker Image now available

+
+
+

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

+
+

Specmatic Docker Image now available Read More »

+
+ +
+
-
+
-
-
-
-

2023 year in review

-
-
-

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come! In this issue:

-
-

2023 year in review Read More »

-
-
+
+
+
+

2023 year in review

+
+
+

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come! In this issue:

+
+

2023 year in review Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
-
-
-
+
+ -
+ +
+
- -
- - -
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1038,7 +1136,7 @@

Categories

- - + + \ No newline at end of file diff --git a/specmatic-updates/page/3/index.html b/specmatic-updates/page/3/index.html index 85b59332a..b983192e9 100644 --- a/specmatic-updates/page/3/index.html +++ b/specmatic-updates/page/3/index.html @@ -3,8 +3,8 @@ - -Specmatic Updates – Page 3 – Specmatic + + Specmatic Updates – Page 3 – Specmatic @@ -15,6 +15,7 @@ + @@ -36,34 +37,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
- -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+
+
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
+
+
+
Redis stubing - specmatic contact development with contract testing.
+

Redis Stubbing with Specmatic Contract Testing

+
+
+

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

+
+

Redis Stubbing with Specmatic Contract Testing Read More »

+
+ +
+
-
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
+
+ -
+ +
+
- -
- - -
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -978,7 +1067,7 @@

Categories

- - + + \ No newline at end of file diff --git a/spotlight/index.html b/spotlight/index.html index 2c74ea55f..70f0f90fc 100644 --- a/spotlight/index.html +++ b/spotlight/index.html @@ -3,8 +3,8 @@ - -Feature Spotlight – Specmatic + + Feature Spotlight – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,32 @@ - + - + - - + + - + - + - - - + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Feature Spotlight

-
-
+
+ + +
+

Feature Spotlight

+ +
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates […]

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates […]

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC

-
-
-

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

-
-
+
+
+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC

+
+
+

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

+
+ +
+
-
+
-
-
-
-

API Resiliency and Contract Testing for GraphQL

-
-
-

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

API Resiliency and Contract Testing for GraphQL Read More »

-
-
+
+
+
+

API Resiliency and Contract Testing for GraphQL

+
+
+

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

API Resiliency and Contract Testing for GraphQL Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic Docker Image now available

-
-
-

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

-
-

Specmatic Docker Image now available Read More »

-
-
+
+
+
+

Specmatic Docker Image now available

+
+
+

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

+
+

Specmatic Docker Image now available Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -1039,7 +1146,7 @@

Categories

- - + + \ No newline at end of file diff --git a/spotlight/page/2/index.html b/spotlight/page/2/index.html index 96405a9e9..a97301865 100644 --- a/spotlight/page/2/index.html +++ b/spotlight/page/2/index.html @@ -3,8 +3,8 @@ - -Feature Spotlight – Page 2 – Specmatic + + Feature Spotlight – Page 2 – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Feature Spotlight

-
-
+
+ + +
+

Feature Spotlight

+ +
+
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
+
+
+
Redis stubing - specmatic contact development with contract testing.
+

Redis Stubbing with Specmatic Contract Testing

+
+
+

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

+
+

Redis Stubbing with Specmatic Contract Testing Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -852,7 +934,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/api-coverage-report/index.html b/tag/api-coverage-report/index.html index edae23544..729f66401 100644 --- a/tag/api-coverage-report/index.html +++ b/tag/api-coverage-report/index.html @@ -3,8 +3,8 @@ - -API Coverage Report – Specmatic + + API Coverage Report – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

API Coverage Report

-
-
+
+ + +
+

API Coverage Report

+ +
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/api-design/index.html b/tag/api-design/index.html index 0df977972..8a2e6fe6a 100644 --- a/tag/api-design/index.html +++ b/tag/api-design/index.html @@ -3,8 +3,8 @@ - -API design – Specmatic + + API design – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- - -
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -839,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/api-mocking/index.html b/tag/api-mocking/index.html index 22c58cecd..5d36092bd 100644 --- a/tag/api-mocking/index.html +++ b/tag/api-mocking/index.html @@ -3,8 +3,8 @@ - -api mocking – Specmatic + + api mocking – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

api mocking

-
-
+
+ + +
+

api mocking

+ +
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/api-testing/feed/index.xml b/tag/api-testing/feed/index.xml index 6c3af9c63..2265de603 100644 --- a/tag/api-testing/feed/index.xml +++ b/tag/api-testing/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/api-testing/index.html b/tag/api-testing/index.html index 3f1012111..649cf9e1f 100644 --- a/tag/api-testing/index.html +++ b/tag/api-testing/index.html @@ -3,8 +3,8 @@ - -API testing – Specmatic + + API testing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

API testing

-
+
+ + +
+

API testing

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/asyncapi/index.html b/tag/asyncapi/index.html index d2fe3fd47..671a3eb49 100644 --- a/tag/asyncapi/index.html +++ b/tag/asyncapi/index.html @@ -3,8 +3,8 @@ - -AsyncAPI – Specmatic + + AsyncAPI – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

AsyncAPI

-
-
+
+ + +
+

AsyncAPI

+ +
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such […]

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such […]

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -904,7 +996,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/bdct/index.html b/tag/bdct/index.html index 452f09a21..11bde75ce 100644 --- a/tag/bdct/index.html +++ b/tag/bdct/index.html @@ -3,8 +3,8 @@ - -BDCT – Specmatic + + BDCT – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

BDCT

-
-
+
+ + +
+

BDCT

+ +
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/bi-directional-contract-testing/index.html b/tag/bi-directional-contract-testing/index.html index 60c3643f2..5ba279253 100644 --- a/tag/bi-directional-contract-testing/index.html +++ b/tag/bi-directional-contract-testing/index.html @@ -3,8 +3,8 @@ - -Bi-Directional Contract Testing – Specmatic + + Bi-Directional Contract Testing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Bi-Directional Contract Testing

-
-
+
+ + +
+

Bi-Directional Contract Testing

+ +
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/cdct/index.html b/tag/cdct/index.html index 46e2fbf73..971c402cf 100644 --- a/tag/cdct/index.html +++ b/tag/cdct/index.html @@ -3,8 +3,8 @@ - -CDCT – Specmatic + + CDCT – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

CDCT

-
-
+
+ + +
+

CDCT

+ +
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/cdd/index.html b/tag/cdd/index.html index e962a2bdb..5a88d3af7 100644 --- a/tag/cdd/index.html +++ b/tag/cdd/index.html @@ -3,8 +3,8 @@ - -CDD – Specmatic + + CDD – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

CDD

-
-
+
+ + +
+

CDD

+ +
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/conference/feed/index.xml b/tag/conference/feed/index.xml index d2ad2428b..c1ccda262 100644 --- a/tag/conference/feed/index.xml +++ b/tag/conference/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/conference/index.html b/tag/conference/index.html index 6216a1269..2504b2a6a 100644 --- a/tag/conference/index.html +++ b/tag/conference/index.html @@ -3,8 +3,8 @@ - -Conference – Specmatic + + Conference – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Conference

-
+
+ + +
+

Conference

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/consumer-driven-contract-testing/index.html b/tag/consumer-driven-contract-testing/index.html index ea5f0bda2..28ee7572a 100644 --- a/tag/consumer-driven-contract-testing/index.html +++ b/tag/consumer-driven-contract-testing/index.html @@ -3,8 +3,8 @@ - -Consumer Driven Contract Testing – Specmatic + + Consumer Driven Contract Testing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Consumer Driven Contract Testing

-
-
+
+ + +
+

Consumer Driven Contract Testing

+ +
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,9 @@

Categories

- - + + + +> \ No newline at end of file diff --git a/tag/consumer-driven-contract/index.html b/tag/consumer-driven-contract/index.html index 8fdf26b3b..a5e908f05 100644 --- a/tag/consumer-driven-contract/index.html +++ b/tag/consumer-driven-contract/index.html @@ -3,8 +3,8 @@ - -Consumer Driven Contract – Specmatic + + Consumer Driven Contract – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Consumer Driven Contract

-
-
+
+ + +
+

Consumer Driven Contract

+ +
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/continuous-delivery/index.html b/tag/continuous-delivery/index.html index 3ad138200..8e7f94ddb 100644 --- a/tag/continuous-delivery/index.html +++ b/tag/continuous-delivery/index.html @@ -3,8 +3,8 @@ - -Continuous Delivery – Specmatic + + Continuous Delivery – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Continuous Delivery

-
-
+
+ + +
+

Continuous Delivery

+ +
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/contract-driven-development/index.html b/tag/contract-driven-development/index.html index 3fbcedd58..fffe31fdd 100644 --- a/tag/contract-driven-development/index.html +++ b/tag/contract-driven-development/index.html @@ -3,8 +3,8 @@ - -Contract Driven Development – Specmatic + + Contract Driven Development – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Contract Driven Development

-
-
+
+ + +
+

Contract Driven Development

+ +
+
-
-
-
-

Contract Testing using gRPC Specs as Executable Contracts

-
-
-

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, […]

-
-

Contract Testing using gRPC Specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing using gRPC Specs as Executable Contracts

+
+
+

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, […]

+
+

Contract Testing using gRPC Specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1030,7 +1140,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/contract-testing/index.html b/tag/contract-testing/index.html index bc7c036a3..5e0976591 100644 --- a/tag/contract-testing/index.html +++ b/tag/contract-testing/index.html @@ -3,8 +3,8 @@ - -Contract Testing – Specmatic + + Contract Testing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Contract Testing

-
-
+
+ + +
+

Contract Testing

+ +
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such […]

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such […]

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1030,7 +1140,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/database-stubbing/index.html b/tag/database-stubbing/index.html index 8214cfb04..7aa83c6ac 100644 --- a/tag/database-stubbing/index.html +++ b/tag/database-stubbing/index.html @@ -3,8 +3,8 @@ - -Database Stubbing – Specmatic + + Database Stubbing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Database Stubbing

-
-
+
+ + +
+

Database Stubbing

+ +
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/demonstration/index.html b/tag/demonstration/index.html index 130107427..a8e3400cf 100644 --- a/tag/demonstration/index.html +++ b/tag/demonstration/index.html @@ -3,8 +3,8 @@ - -Demonstration – Specmatic + + Demonstration – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Demonstration

-
-
+
+ + +
+

Demonstration

+ +
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have […]

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have […]

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -883,7 +972,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/google-pub-sub/index.html b/tag/google-pub-sub/index.html index ab4b2294d..2416d8002 100644 --- a/tag/google-pub-sub/index.html +++ b/tag/google-pub-sub/index.html @@ -3,8 +3,8 @@ - -Google Pub/Sub – Specmatic + + Google Pub/Sub – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Google Pub/Sub

-
-
+
+ + +
+

Google Pub/Sub

+ +
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such […]

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such […]

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/graphql/index.html b/tag/graphql/index.html index dbefa370e..cc2e04a98 100644 --- a/tag/graphql/index.html +++ b/tag/graphql/index.html @@ -3,8 +3,8 @@ - -GraphQL – Specmatic + + GraphQL – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

GraphQL

-
-
+
+ + +
+

GraphQL

+ +
+
-
-
-
-

API Resiliency and Contract Testing for GraphQL

-
-
-

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, […]

-
-

API Resiliency and Contract Testing for GraphQL Read More »

-
-
+
+
+
+

API Resiliency and Contract Testing for GraphQL

+
+
+

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, […]

+
+

API Resiliency and Contract Testing for GraphQL Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/grpc/index.html b/tag/grpc/index.html index 0b1d24d83..f8e8264de 100644 --- a/tag/grpc/index.html +++ b/tag/grpc/index.html @@ -3,8 +3,8 @@ - -gRPC – Specmatic + + gRPC – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

gRPC

-
-
+
+ + +
+

gRPC

+ +
+
-
-
-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

-
-
-

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe […]

-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

-
-
+
+
+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

+
+
+

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe […]

+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing using gRPC Specs as Executable Contracts

-
-
-

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

Contract Testing using gRPC Specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing using gRPC Specs as Executable Contracts

+
+
+

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

Contract Testing using gRPC Specs as Executable Contracts Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/http/index.html b/tag/http/index.html index 33c0e9baf..b2672cd90 100644 --- a/tag/http/index.html +++ b/tag/http/index.html @@ -3,8 +3,8 @@ - -HTTP – Specmatic + + HTTP – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

HTTP

-
-
+
+ + +
+

HTTP

+ +
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/integration-testing/index.html b/tag/integration-testing/index.html index bab4deb3b..855615388 100644 --- a/tag/integration-testing/index.html +++ b/tag/integration-testing/index.html @@ -3,8 +3,8 @@ - -Integration Testing – Specmatic + + Integration Testing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Integration Testing

-
-
+
+ + +
+

Integration Testing

+ +
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/jdbc/index.html b/tag/jdbc/index.html index 7cf7a6876..ad3b1ac90 100644 --- a/tag/jdbc/index.html +++ b/tag/jdbc/index.html @@ -3,8 +3,8 @@ - -JDBC – Specmatic + + JDBC – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

JDBC

-
-
+
+ + +
+

JDBC

+ +
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/jms/index.html b/tag/jms/index.html index 733ff971b..809a70f2e 100644 --- a/tag/jms/index.html +++ b/tag/jms/index.html @@ -3,8 +3,8 @@ - -JMS – Specmatic + + JMS – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

JMS

-
-
+
+ + +
+

JMS

+ +
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/kafka/index.html b/tag/kafka/index.html index 03878db41..0c95a6fb0 100644 --- a/tag/kafka/index.html +++ b/tag/kafka/index.html @@ -3,8 +3,8 @@ - -Kafka – Specmatic + + Kafka – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Kafka

-
-
+
+ + +
+

Kafka

+ +
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have […]

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have […]

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/live-stream/feed/index.xml b/tag/live-stream/feed/index.xml index aa26ad3f8..2c20c2ff2 100644 --- a/tag/live-stream/feed/index.xml +++ b/tag/live-stream/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/live-stream/index.html b/tag/live-stream/index.html index 81485b455..95547e21e 100644 --- a/tag/live-stream/index.html +++ b/tag/live-stream/index.html @@ -3,8 +3,8 @@ - -Live Stream – Specmatic + + Live Stream – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Live Stream

-
+
+ + +
+

Live Stream

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/microservices/index.html b/tag/microservices/index.html index 7cd446392..e5f179bd8 100644 --- a/tag/microservices/index.html +++ b/tag/microservices/index.html @@ -3,8 +3,8 @@ - -microservices – Specmatic + + microservices – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

microservices

-
-
+
+ + +
+

microservices

+ +
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/openapi/index.html b/tag/openapi/index.html index 6be207357..006a9bb58 100644 --- a/tag/openapi/index.html +++ b/tag/openapi/index.html @@ -3,8 +3,8 @@ - -OpenAPI – Specmatic + + OpenAPI – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

OpenAPI

-
-
+
+ + +
+

OpenAPI

+ +
+
-
-
-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

-
-
-

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

-
-
+
+
+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

+
+
+

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

-
-
-

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

-
-
+
+
+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

+
+
+

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1009,7 +1116,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/pact/index.html b/tag/pact/index.html index 0581c6308..4ba833925 100644 --- a/tag/pact/index.html +++ b/tag/pact/index.html @@ -3,8 +3,8 @@ - -pact – Specmatic + + pact – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

pact

-
-
+
+ + +
+

pact

+ +
+
-
-
-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

-
-
-

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven […]

-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

-
-
+
+
+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+
+
+

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven […]

+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/pactflow/index.html b/tag/pactflow/index.html index 7ed5374e5..12ca1f35a 100644 --- a/tag/pactflow/index.html +++ b/tag/pactflow/index.html @@ -3,8 +3,8 @@ - -Pactflow – Specmatic + + Pactflow – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,32 @@ - + - + - - + + - + - + - - - + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Pactflow

-
-
+
+ + +
+

Pactflow

+ +
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/past/feed/index.xml b/tag/past/feed/index.xml index 77991ad97..6f059750a 100644 --- a/tag/past/feed/index.xml +++ b/tag/past/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/past/index.html b/tag/past/index.html index cfb2e0fdc..37814d8f4 100644 --- a/tag/past/index.html +++ b/tag/past/index.html @@ -3,8 +3,8 @@ - -Past – Specmatic + + Past – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Past

-
+
+ + +
+

Past

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/provider-driven-contract/index.html b/tag/provider-driven-contract/index.html index b618a8d70..160bfe14a 100644 --- a/tag/provider-driven-contract/index.html +++ b/tag/provider-driven-contract/index.html @@ -3,8 +3,8 @@ - -Provider Driven Contract – Specmatic + + Provider Driven Contract – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Provider Driven Contract

-
-
+
+ + +
+

Provider Driven Contract

+ +
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/redis/index.html b/tag/redis/index.html index 457d4aed8..aebf4c2c7 100644 --- a/tag/redis/index.html +++ b/tag/redis/index.html @@ -3,8 +3,8 @@ - -Redis – Specmatic + + Redis – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Redis

-
-
+
+ + +
+

Redis

+ +
+
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
+
+
+
Redis stubing - specmatic contact development with contract testing.
+

Redis Stubbing with Specmatic Contract Testing

+
+
+

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

+
+

Redis Stubbing with Specmatic Contract Testing Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/resiliency-testing/feed/index.xml b/tag/resiliency-testing/feed/index.xml index 74b4dd558..460dad277 100644 --- a/tag/resiliency-testing/feed/index.xml +++ b/tag/resiliency-testing/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/resiliency-testing/index.html b/tag/resiliency-testing/index.html index f464ddc18..558bd6231 100644 --- a/tag/resiliency-testing/index.html +++ b/tag/resiliency-testing/index.html @@ -3,8 +3,8 @@ - -Resiliency testing – Specmatic + + Resiliency testing – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Resiliency testing

-
+
+ + +
+

Resiliency testing

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/shift-left/feed/index.xml b/tag/shift-left/feed/index.xml index 457abd703..d2697edd0 100644 --- a/tag/shift-left/feed/index.xml +++ b/tag/shift-left/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/shift-left/index.html b/tag/shift-left/index.html index 1e4c28cde..cf43fdf07 100644 --- a/tag/shift-left/index.html +++ b/tag/shift-left/index.html @@ -3,8 +3,8 @@ - -Shift Left – Specmatic + + Shift Left – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Shift Left

-
+
+ + +
+

Shift Left

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/specmatic/index.html b/tag/specmatic/index.html index 9069db164..9d039b9de 100644 --- a/tag/specmatic/index.html +++ b/tag/specmatic/index.html @@ -3,8 +3,8 @@ - -Specmatic – Specmatic + + Specmatic – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,32 @@ - + - + - - + + - + - + - - - + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Specmatic

-
-
+
+ + +
+

Specmatic

+ +
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates […]

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates […]

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -946,7 +1042,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/spring-cloud-contract/index.html b/tag/spring-cloud-contract/index.html index 5c5d71b45..92a402b5a 100644 --- a/tag/spring-cloud-contract/index.html +++ b/tag/spring-cloud-contract/index.html @@ -3,8 +3,8 @@ - -Spring Cloud Contract – Specmatic + + Spring Cloud Contract – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Spring Cloud Contract

-
-
+
+ + +
+

Spring Cloud Contract

+ +
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -841,7 +924,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/stubbing/index.html b/tag/stubbing/index.html index fe232b8a4..e69de29bb 100644 --- a/tag/stubbing/index.html +++ b/tag/stubbing/index.html @@ -1,889 +0,0 @@ - - - - - - -Stubbing – Specmatic - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
-
-
-
-

Stubbing

-
-
- -
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
-
-
-
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
-
-
-
-
- -
-
-
-
-
-
-
- -
- - -
-
-
-
- - - -
-
- - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/tag/upcoming/feed/index.xml b/tag/upcoming/feed/index.xml index ebaf7333d..4e443c2b7 100644 --- a/tag/upcoming/feed/index.xml +++ b/tag/upcoming/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/tag/upcoming/index.html b/tag/upcoming/index.html index 9f0009af5..dd19a1cd4 100644 --- a/tag/upcoming/index.html +++ b/tag/upcoming/index.html @@ -3,8 +3,8 @@ - -Upcoming – Specmatic + + Upcoming – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Upcoming

-
+
+ + +
+

Upcoming

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file diff --git a/tag/wiremock/index.html b/tag/wiremock/index.html index 28d62e945..0752cb16a 100644 --- a/tag/wiremock/index.html +++ b/tag/wiremock/index.html @@ -3,8 +3,8 @@ - -wiremock – Specmatic + + wiremock – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

wiremock

-
-
+
+ + +
+

wiremock

+ +
+
-
-
-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

-
-
-

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of […]

-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

-
-
+
+
+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

+
+
+

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of […]

+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -862,7 +948,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/2023-year-in-review/index.html b/updates/2023-year-in-review/index.html index 051f622c2..4bcd5278f 100644 --- a/updates/2023-year-in-review/index.html +++ b/updates/2023-year-in-review/index.html @@ -3,8 +3,8 @@ - -2023 year in review - Specmatic + + 2023 year in review - Specmatic @@ -15,6 +15,7 @@ + @@ -53,36 +54,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

2023 year in review

+ + + +
+ + +

2023 year in review

-
-
+Updates / By + +
+ + +
+ + + +
+ + +

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come!

+ + +

In this issue:

+ + + + + + + + +

Conference appearances

+ + +

The team has presented at several conferences this year including Agile India 2023, YOW in Australia and AsyncAPI on Tour in Bangalore plus many smaller Meetups. They’ve been spreading the word about the benefits of CDD and how Specmatic can help make it all happen.

-
+ + + +
+ + + + + +

Look inside your microservices implementation with Specmatic Insights

+ + +

Specmatic Insights is a new tool that aggregates Specmatic reports from various environments such as your CI/CD pipelines, and visualizes how your organization’s microservices talk to each other, providing actionable insights.

+ + +
+ + + + + + + + + + + +

Contract testing made even easier with VSCode extension

+ + +

The new Specmatic VSCode extension makes it easy to set up and run your contract tests from within VSCode. An interactive UI takes care of your configurations for running contract tests and remembers your settings for future tests. It can also automatically generate examples and test data for your OpenAPI specifications using GPT-4.

-
+ + + +
+ + + + + + + + + + + +

Word is getting out!

+ + +

This year, others have been picking up on the benefits of Contract Driven Development and how Specmatic facilitates a CDD workflow.

+ + +

In March, InfoQ published an article outlining an organization’s Contract-Driven Development adoption journey. It covers off the many benefits of CDD as well as how the organization overcame some of the challenges.

+ + +
A man is pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+ + +

Dave Farley posted a video on “Easy Microservice Testing” with Specmatic to his Continuous Delivery YouTube channel which sparked some lively conversation.

+ + +

Serghei Lakovlev has created a handy action to set up a Specmatic environment for use in Github actions.

+ + +

Markus Oberlehner discovered the benefits of stubbing endpoints with Spermatic and shared his thoughts on YouTube.

+ + +

Geovanny Ribeiro shared on LinkedIn when he discovered he could stub http APIs with their OpenAPI specifications and mock a Kafka broker with AsyncAPI specification.

+ + + + + +

Specmatic explainer videos

+ + +

This year we’ve produced a series of videos to help people understand the benefits of Contract-Driven Development and how Specmatic works. You’ll find them on the Specmatic website and on our YouTube channel.

-
+ + + +
+ + + + + +

Specmatic Contributors

+ + +

We are thrilled to have a group of talented contributors to the Specmatic project. With 40 forks and 163 stars, we have an active community! Thanks to everyone who has contributed code this past year, we appreciate your efforts:

+ + +

Andre Roaldseth, Christophe Lopez, Hari Krishnan, Jaydeep Kulkarni, Joel Rosario, Lingxu Meng, Markus Oberlehner, Naresh Jain, Naresh Kumar, Rahul Shekhawat, Rosdi Kasim, Samuel Antoine, Swamideshmukh, Vikram Rao, Westse, Yntelectual, and Zapheus-Runplaywin.

+ + +

Latest Specmatic release: 1.1.0

+ + +

Recent releases include the following updates:

+ + +
  • #721 Implemented support for the RFC3339 datetime format. by @jaydeepk in #846
  • + + +
  • Repo report order stability by @westse in #851
  • + + +
  • Fixed proxy error when converging array types by @joelrosario in #855
  • + + +
  • Support for all syntactical equivalents of free form objects by @jaydeepk in #853
  • + + +
  • Support json and yml extensions by @harikrishnan83 in #854
  • + + +
  • Added support for minProperties and maxProperties
  • + + +
  • Added support for oneOf nested within allOf
  • + + +
  • Use schema example as the default example
+ + +

You can download the latest version here.

+ + + + + +

Features released in 2023

+ + +

We’ve been busy with 40 updates made to the project this year! A lot of new capabilities have been added to Specmatic in response to user requirements including:

+ + +
  • API coverage reports
  • + + +
  • Redis stub – private beta
  • + + +
  • Hooks for emulating payment gateways
  • + + +
  • Node wrapper v2
  • + + +
  • JDBC stub – private beta
  • + + +
  • Python wrapper
  • + + +
  • AsyncAPI Kafka support – private beta
+ + + + + +

Coming up next…

+ + +

Here is a peak at some of the features we are planning to develop next in Specmatic:

+ + +
  • AsyncAPI General Availability
  • + + +
  • AsyncAPI v3 support (beta)
  • + + +
  • OpenAPI links support
  • + + +
  • OpenAPI 3.1 support
+ + + + + + + + +

As always, we’d love to hear how you are using Specmatic and how Contract-Driven Development has transformed your microservices development and deployment experience. What have been your challenges and what have been your wins? Got questions? Contact us and ask away.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1032,7 +1359,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/build-apps-from-api-specs-using-ai-self-correcting-contract-driven-agentic-workflows-with-specmatic/index.html b/updates/build-apps-from-api-specs-using-ai-self-correcting-contract-driven-agentic-workflows-with-specmatic/index.html index 5d1cf9d7f..05701a39c 100644 --- a/updates/build-apps-from-api-specs-using-ai-self-correcting-contract-driven-agentic-workflows-with-specmatic/index.html +++ b/updates/build-apps-from-api-specs-using-ai-self-correcting-contract-driven-agentic-workflows-with-specmatic/index.html @@ -3,8 +3,8 @@ - -Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic + + Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic @@ -15,6 +15,7 @@ + @@ -52,36 +53,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

+ + + +
+ + +

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

-
-
+Demonstration, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Harnessing the Power of API Specifications for Robust Microservices 

+ + +

Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. This article explores how AI can leverage API specifications to create a robust service with a downstream dependency, emphasizing the process, benefits, and challenges of employing such a system. 

+ + +

AI-Driven Application Development: A Case Study 

+ + +

Here’s a practical example to illustrate the capability of agentic AI. Consider an order service that needs to interact with a product service for details like product price and description. By feeding the OpenAPI specifications of both services into an intelligent agent, the AI can generate a running application, even easing the traditionally tedious task of setting up stubs for dependencies. 

+ + +

Step-by-Step Application Generation 

+ + +

The AI begins by asking an LLM to generate a Node.js application for the order service. The agent then uses a suite of tools to start the order service, stubs out its product service dependency using the product service OpenAPI specification, then runs a series of contract tests against the order service. Not surprisingly, these tests may fail initially. In our example, they did fail, but this is where the power of feedback loops comes into play. 

+ + +

Feedback loops provide Guardrails 

+ + +

Failed tests serve as deterministic feedback for the AI. The LLM reads these failures, understands the points of contention—such as the validation of data types—and attempts to rectify them. For instance, one of the negative contract tests generated from the specification passed a null value to a discount_coupon parameter, which was a non-nullable property as per the specification. The first version of the order service accepted this value, instead of returning a 400 Bad Request response. The contract tests caught this and provided clear feedback, enabling the LLM to adjust and re-run the tests. 

+ + +

Stubbing Dependencies 

+ + +

One of the noteworthy aspects is how the agent manages dependencies. Given that only the order service is being generated, the product service needs to be simulated. This is achieved through dependency stubbing based on the product service’s OpenAPI specification. By creating a stub, the agent ensures that the order service can interact with a mock version of the product service, thereby validating its behavior under realistic conditions. 

+ + +

Achieving a Running Application 

+ + +

As the AI makes iterative adjustments based on the feedback from contract tests, it eventually gets all the tests to pass. When the tests pass, it implies that the order service is adhering correctly to the OpenAPI specification and is tuned to handle all expected data types and scenarios. 

+ + +

The Role of Deterministic Feedback & Iterative Refinement 

+ + +

AI systems, especially LLMs, are inherently non-deterministic and often require iterative refinement to achieve the desired outcome. This unpredictability is counterbalanced by deterministic feedback from contract tests generated from the OpenAPI specification. Each iteration of feedback and corresponding adjustments brings the application closer to full compliance with the API specifications. 

+ + +

In our case, the AI underwent multiple iterations. Initially, the system generated code, executed contract tests with Specmatic, and faced failures. With each cycle, the AI learned from its mistakes, improving the application until all contract tests passed successfully. The final result was an order service that adhered strictly to its API specifications and could reliably interact with the stubbed product service. 

+ + +

Advantages of Contract-Driven Development and AI 

+ + +

Amalgamating AI with Contract-Driven Development, offers development teams several advantages: 

+ + +
  • Automated Application Creation 
    AI can autonomously generate applications based on specifications, significantly reducing manual coding effort. 
+ + +
  • Robust Testing 
    Contract tests ensure that the application behaves correctly, adhering to API specifications. 
+ + +
  • Efficient Integration 
    Dependency stubbing allows seamless inter-service communication, even when actual services are not available during the development phase. 
+ + +
  • Continuous Feedback 
    Deterministic tests provide ongoing feedback, enabling the AI to make necessary adjustments autonomously. 
+ + +

Conclusion 

+ + +

Integrating AI with contract-driven development workflows marks a significant advancement in how we build and manage microservices. By leveraging API specifications and iterative feedback loops through contract testing, we can achieve more reliable and compliant services. This approach not only accelerates development but also minimizes integration issues, ensuring that services function as intended from the outset. 

+ + +

The journey from API specifications to fully functional applications is not without challenges. However, by embracing tools and methodologies that provide clear, executable contracts, we can streamline the development process, harness the power of microservices, and build systems that are both robust and agile. 

+ + +

+ + + +
+
-
+ + - -
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -981,7 +1164,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/contract-testing-using-grpc-specs-as-executable-contracts/index.html b/updates/contract-testing-using-grpc-specs-as-executable-contracts/index.html index 4586047a6..6d0da9cfa 100644 --- a/updates/contract-testing-using-grpc-specs-as-executable-contracts/index.html +++ b/updates/contract-testing-using-grpc-specs-as-executable-contracts/index.html @@ -3,8 +3,8 @@ - -Contract Testing using gRPC Specs as Executable Contracts - Specmatic + + Contract Testing using gRPC Specs as Executable Contracts - Specmatic @@ -15,6 +15,7 @@ + @@ -54,36 +55,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Contract Testing using gRPC Specs as Executable Contracts

+ + + +
+ + +

Contract Testing using gRPC Specs as Executable Contracts

-
-
+Updates / By + +
+ + +
+ + + +
+ + +
+ + +

Transform your gRPC API specs into executable contracts in seconds

+ + +

Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, thereby making for a one stop solution that enables a seamless DevEx. 

-
+ + + +
+ + + + + +

Streamlining Microservices Development with Contract-Driven Testing

+ + +

In the evolving world of microservices, ensuring robust and reliable communication between services is no small feat. Services need to interact efficiently without introducing bottlenecks or faults that could lead to system failures. Specmatic is a powerful tool that simplifies the contract testing of gRPC services, thereby enhancing the resilience and dependability of microservice architectures.

+ + +

Understanding the Architecture

+ + +

Our application comprises three key components: the client, the Backend-for-Frontend (BFF) service, and the backend domain service. The glue binding these components together is the gRPC protocol, renowned for its performance and efficiency. Testing these components in isolation becomes paramount to ensure independent functionality and overall system stability.

+ + +

Specmatic steps into this context to make the otherwise daunting task of contract testing straightforward and maintainable. In testing mode, Specmatic replaces the real client with a simulated client and the backend domain service with a gRPC stub, mimicking its interactions and responses.

+ + +

The Power of Specmatic in Isolated Testing

+ + +

In isolation testing, the aim is to test the BFF service without depending on the client or the backend domain service. This setup leverages Specmatic, which acts as a substitute for these components by emulating their behavior. By doing so, Specmatic effectively validates the interactions and ensures they comply with the defined contract.

+ + +

Specmatic achieves this by generating a stub based on the API specification file of the backend domain service. This stub is a highly accurate representation, ensuring the BFF behaves correctly even in the absence of actual backend services. This results in faster and more efficient tests.

+ + +

Exploring the gRPC Methods and Tests

+ + +

Let’s dive deeper into the testing methodology by examining the gRPC methods and the corresponding tests. A typical RPC method such as create order expects a request containing a new order’s details and returns an order ID. Specmatic tests validate these interactions against the specified contract.

+ + +

Valid Request Testing

+ + +

When a valid request, adhering to all required fields and constraints, is sent to the BFF service, Specmatic ensures the response is validated correctly against the schema. If the responses conform to the expected contract, the tests pass seamlessly, confirming the service’s behavior.

+ + +

Negative Scenario Testing

+ + +

Specmatic also excels in testing negative scenarios, known as mutation-based testing. Consider a scenario where a request field such as count is below the minimum value defined by the contract. Specmatic expects an appropriate error response. If the service fails to handle this correctly and returns a valid response instead, Specmatic identifies the issue, flags the test, and highlights exactly where the problem lies.

+ + +

This meticulous approach extends to other tests, such as missing required fields. Specmatic checks for the appropriate error handling, ensuring that every plausible negative scenario is rigorously tested.

+ + +

Automated Test Generation and Execution

+ + +

One of the standout features of Specmatic is its ability to auto-generate tests. Developers do not need to handcraft each test case; instead, Specmatic uses the API specifications to generate comprehensive tests covering various scenarios. This automation dramatically reduces the overhead and ensures no critical test cases are overlooked.

+ + +

The Specmatic Configuration File

+ + +

The real magic lies in the Specmatic configuration file, a YAML file detailing the specifications and configurations necessary for Specmatic to operate. This file specifies the specs for the BFF service and the domain services it depends on, guiding Specmatic’s test generation and stub creation processes.

+ + +

Enhancing Microservices Reliability

+ + +

The adoption of Specmatic in contract-driven development offers numerous benefits:

+ + +
  • Early Detection of Integration Issues: By validating interactions early in the development cycle, integration issues are identified and resolved promptly.
  • + + +
  • Reduced Dependency on Live Services: Eliminates the need to run actual dependent services, thus simplifying the testing workflow.
  • + + +
  • Assurance of Compliance: Ensures all interactions adhere strictly to the agreed-upon API contracts, fostering consistency and reliability.
  • + + +
  • Boosted Developer Confidence: With exhaustive tests ensuring all scenarios are covered, developers gain increased confidence in the stability and resilience of the microservices.
+ + +

Conclusion

+ + +

Specmatic revolutionizes the way developers approach contract testing in gRPC services. Its ability to simulate clients and backend services, generate exhaustive tests, and validate interactions against strict contracts ensures that microservices can be developed, tested, and deployed with greater confidence. By maintaining API specifications centrally and automating test generation, Specmatic embodies the best practices of contract-driven development.

+ + +

Getting Started

+ + +

For gRPC, the setup process is just as straightforward as it is for OpenAPI. All you need are your gRPC proto files, along with a simple Specmatic configuration, and you’re good to go!

+ + +

Sample gRPC projects

+ + +

https://github.com/znsio/specmatic-order-bff-grpc-kotlin 
https://github.com/znsio/specmatic-order-api-grpc-kotlin 
https://github.com/znsio/specmatic-order-bff-grpc-go 

+ + +

Give a star to Specmatic – https://github.com/znsio/specmatic  

+ + +

Available in the Pro plan or higher

+ + + + + + + + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -986,7 +1208,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html b/updates/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html index bbd7e518f..bcc8a2a40 100644 --- a/updates/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html +++ b/updates/detect-mismatches-between-your-api-specifications-and-implementation-specmatic-api-coverage-report/index.html @@ -3,8 +3,8 @@ - -Early detection of mismatches between your API specs and app implementation + + Early detection of mismatches between your API specs and app implementation @@ -15,6 +15,7 @@ + @@ -57,36 +58,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+ + + +
+ + +

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

The problem

+ + +

Incomplete API specifications impact feature awareness for consumers and undocumented features cannot be verified against API design standards through linters. Moreover such specifications can neither be leveraged for stubbing / service virtualization nor for contract testing.

+ + +

Key Benefits of the Specmatic API Coverage Report

+ + +

Specmatic’s API coverage report makes it easy to identify and fix mismatches between an OpenAPI specification and an application’s implementation.

+ + +
  1. Identify mismatches between OpenAPI specifications and implementations early in your development cycle.
  2. + + +
  3. Detect paths and methods which are implemented in the application, but not documented in the API specification and vice-versa.
  4. + + +
  5. Fail your CI builds based on API Coverage Report success criteria to prevent mismatches between API specifications and implementations from propagating further.
+ + +

Check out the sample code

+ + +

Sample Java project:
https://github.com/znsio/specmatic-order-api-java

+ + +

Sample Python projects:
https://github.com/znsio/specmatic-order-api-python
https://github.com/znsio/specmatic-order-bff-python
https://github.com/znsio/specmatic-order-bff-python-sanic

+ + +

Sample NodeJS project
https://github.com/znsio/specmatic-order-bff-nodejs

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

-
+ + + +
+ + + + + +

Generating an API coverage report

+ + +

If you have an application which has a route and an OpenAPI specification in which this route is documented, Specmatic can leverage the OpenAPI specification as an executable contract and run contract tests against the application. If the implementation of the route matches the specification, then Specmatic will report the contract test as passed. 

+ + +

What if you document a new path in the specification but fail to actually implement it in the application? Now, any API consumers who use this spec will get a 404 error when they hit this unimplemented path. It could also happen that you add a new route in the application but fail to document it in the specification. The OpenAPI specification is now incomplete and it does not accurately describe the application’s endpoints. An incomplete specification is a huge problem and has serious implications. 

+ + +
  1. The effectiveness of your contract test is compromised. 
  2. + + +
  3. Any API consumers who use this spec will never become aware of the missing path. This will also impact those API consumers who wish to leverage this spec as a stub. You won’t be able to detect API compatibility breakage. 
  4. + + +
  5. You won’t be able to enforce organizational API standards using linters on the undocumented endpoints. 
+ + +

This is exactly the problem that the Specmatic API coverage report solves. Specmatic can detect an application’s endpoints and generate a comprehensive API coverage report. The API coverage report helps us to identify any mismatch between the OpenAPI specification and the application early in the development lifecycle. You can also prevent these issues from propagating any further by failing the CI pipeline build if the API coverage report detects any mismatch.

+ + + + + +

Code walkthrough: API Coverage report in action

+ + +

In this example, we have a Springboot application with a bunch of controllers with routes implemented in them. We also have an OpenAPI specification for this app with all the endpoints described.

-
+ + + +
+ + + + + +

When running a contract test, the key aspect to note is the Endpoints API property, through which Specmatic will determine all the endpoints implemented in the app.

-
+ + + +
+ + + + + +

+ + +

Since this is a Springboot application, we use the mappings endpoint provided by the spring actuator library. When running the example test you’ll see there’s one test which has failed as well in the build.

-
+ + + +
+ + + + + +

API Coverage Report Walkthrough

-
+ + + +
+ + + + + +

The API coverage report lists all the endpoints with their methods and response codes. For every endpoint, it reports the coverage and also indicates if the endpoint is missing in the spec or not implemented in the application. It also reports how many times a particular endpoint was called during the test execution. There are three main issues identified in this example. 

+ + +
  1. The /health endpoint is missing in the spec. 
  2. + + +
  3. The GET method of the products/{id} endpoint is also missing in the spec.
  4. + + +
  5. The products/{id}/inventory endpoint is present in the specification, but not implemented in the app. The corresponding test for this endpoint has also failed. 
+ + +

Below this, you can see that the success criteria for the API coverage report has not been met.

-
+ + + +
+ + + + + +

Let’s dig into this further. The success criteria for the API coverage report is defined in the report configuration section of the specmatic.json file. 

+ + +
  • You can define a minimum overall API coverage required for the build to succeed. 
  • + + +
  • You can define the maximum number of endpoints that can be found missing in the specification. 
-
+ + + +
+ + + + + +

Specmatic can be configured to enforce the above success criteria and fail the build if either any of them are not met. 

+ + +

With this in mind, let’s revisit the API coverage report and try to fix these issues.

+ + +

First, let us implement the missing endpoint which is present in the specification, but not available in the app.

+ + +

After implementing the missing endpoint, when we re-run the test you’ll see that where it previously failed it is now passing.

-
+ + + +
+ + + + + +

But the build will still fail because the success criteria of the API coverage report have not been met. Total API coverage is still 79%, whereas the required threshold is set to 100%. Also, there are two endpoints in the application that have not been documented in the specification and the maximum threshold for missing endpoints in the specification is zero.

-
+ + + +
+ + + + + +

Let us add the missing GET method for the product/{id} endpoint to the specification and try running the test again. Please note that apart from adding the GET method, we also need to include examples for the same, without which Specmatic would still consider it as missing in spec.

+ + +

In the coverage report, you’ll now see that this GET method is reported as covered.

-
+ + + +
+ + + + + +

The build fails again because the success criteria still hasn’t been met. The API coverage now is 83%, less than the threshold of 100%, and there is still one missing endpoint in the specification, and that’s the health endpoint. 

+ + +

It’s possible you want to exclude certain monitoring endpoints like health and heartbeat from the coverage report. This can be done in the report configuration section of Specmatic’s config file by adding the URL in the excluded endpoints array.

-
+ + + +
+ + + + + +

Running the test again you’ll see all tests are passing. The API coverage is 100% and there are no missing endpoints in the specification. The success criteria of the API coverage report have been met, and the build passes as well. 

-
+ + + +
+ + + + + +

This should give you an idea of what a powerful tool the API coverage report is and how it helps ensure that your OpenAPI specifications accurately describe your application. 

+ + +

The OpenAPI coverage report is available now for:

+ + +
  • Java Springboot
  • + + +
  • Node.js
  • + + +
  • Python
+ + + + + +

Continuous Integration Build

+ + +

As mentioned earlier, we can fail the CI builds based on API coverage success criteria. Here is an example Github action that has failed on a pull request pre-merge check because an endpoint was added to the implementation without updating the API specification.

-
-
+ + + +
+ + + +
+ + + + + +

Check out the sample code

+ + +

Sample Java project:
https://github.com/znsio/specmatic-order-api-java

+ + +

Sample Python projects:
https://github.com/znsio/specmatic-order-api-python
https://github.com/znsio/specmatic-order-bff-python
https://github.com/znsio/specmatic-order-bff-python-sanic

+ + +

Sample NodeJS project
https://github.com/znsio/specmatic-order-bff-nodejs

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1037,7 +1397,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/grpc-flaws-the-illusion-of-safety-frustrating-devex-in-proto3s-type-safe-contracts/index.html b/updates/grpc-flaws-the-illusion-of-safety-frustrating-devex-in-proto3s-type-safe-contracts/index.html index eb01a1f36..9de2bbd61 100644 --- a/updates/grpc-flaws-the-illusion-of-safety-frustrating-devex-in-proto3s-type-safe-contracts/index.html +++ b/updates/grpc-flaws-the-illusion-of-safety-frustrating-devex-in-proto3s-type-safe-contracts/index.html @@ -3,8 +3,8 @@ - -gRPC Flaws​ - The Illusion of Safety & Frustrating DevEx + + gRPC Flaws​ - The Illusion of Safety & Frustrating DevEx @@ -15,6 +15,7 @@ + @@ -52,36 +53,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

+ + + +
+ + +

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

-
-
+Demonstration, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap 

+ + +

In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe contracts. Discover the significant benefits of contract testing in addressing common issues and enhancing developer experience. 

+ + +

Understanding gRPC and Its Promises – Type-Safety and Schema Enforcement 

+ + +

gRPC has gained traction in the development landscape due to its promise of performance and the enforcement of type-safe contracts via protocol buffers (protobuf). It leverages proto files to define schemas, ensuring that data types and structures remain consistent across different services and platforms. This theoretically eradicates a multitude of problems, promoting backward and forward compatibility while automatically generating client and server code in various languages. 

+ + +

The Reality Check: Identifying gRPC’s Flaws – Handling Requests and Responses 

+ + +

Despite gRPC’s promise, we can demonstrate several important flaws in its operation. For example, let’s use a proto file called order BFF proto, that exhibits three RPC methods: FindAvailableProducts, CreateOrder, and CreateProduct. We can seamlessly create a product using the gRPC web UI. However, omitting crucial information prompts an unexpected response— the product is created successfully despite missing mandatory details. This revelation underscores an overlooked pitfall in gRPC: the lack of built-in support for mandatory parameters enforcement. 

+ + +

Employing Validation Libraries 

+ + +

Proto 3 dropped required fields here is the link to the related Github discussion. However, we can leverage external libraries such as buf.validate to define mandatory parameters. Updating the proto file to validate mandatory fields ensures that requests lacking essential information trigger appropriate validation errors. However, the scenario evolves in our demonstration when a product manager imposes a new constraint: inventory can only be in multiples of three. 

+ + +

The Developer’s Dilemma – Code Changes and Proto File Mismatch 

+ + +

A developer can incorporate this constraint directly into the code, checking if the inventory value adheres to the new rule. While the immediate implementation seems effective, a discrepancy arises—the constraint is absent from the proto file. This highlights a critical issue: the proto file is now out of sync with the actual implementation, leading to potential misunderstandings and errors for downstream consumers. 

+ + +

The Role of Contract Testing 

+ + +

Contract Test Implementation 

+ + +

Contract testing is an effective remedy for such issues. Using the Specmatic framework, developers can write executable contract tests that verify the alignment between the proto file and the actual implementation. Specmatic automatically generates these tests, and upon execution in our demonstration, it reveals two critical test failures. One involves sending a request with an inventory not being a multiple of three, highlighting the previously unnoticed mismatch. 

+ + +

Immediate Feedback and Resolution 

+ + +

Specmatic’s feedback loop proves invaluable, instantly notifying developers of the discrepancy. This immediate feedback ensures that the proto file is updated in tandem with the implementation, preventing downstream misunderstandings and ensuring a consistent developer experience across the board. 

+ + +

Conclusion: Embracing Contract-Driven Development 

+ + +

A Better Developer Experience 

+ + +

So, it is evident that while gRPC offers advantages, it is not without its flaws. The manual nature of validating mandatory fields and the potential misalignment between proto files and implementation can lead to a subpar developer experience. However, integrating contract-driven development practices, exemplified by Specmatic, can bridge these gaps. 

+ + +

Collaboration and Consistency 

+ + +

Maintaining a central Git repository for API specifications is essential. This ensures that all stakeholders—be they providers or consumers—operate with an up-to-date version of the specification. This approach eradicates discrepancies and fosters a culture of collaboration and consistency. 

+ + +

The Path Forward 

+ + +

Ultimately, embracing contract testing in conjunction with gRPC’s strengths paves the way for a more robust and developer-friendly API ecosystem. By addressing the flaws we have highlighted, developers can build more reliable, consistent, and efficient microservices, leading to enhanced productivity and faster deployment. 

+ + +

Final Thoughts 

+ + +

This demonstration serves as a reminder that even the most promising technologies can benefit from supplementary practices. Contract testing is not just a tool; it’s a paradigm that aligns implementation with intent, transforming gRPC’s potential into a reality that developers can rely on. 

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -975,7 +1155,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/index.html b/updates/index.html index 535bf836e..376ad6c76 100644 --- a/updates/index.html +++ b/updates/index.html @@ -3,8 +3,8 @@ - -Updates – Specmatic + + Updates – Specmatic @@ -15,6 +15,7 @@ + @@ -35,34 +36,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Updates

-
-
+
+ + +
+

Updates

+ +
+
-
-
-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

-
-
-

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

-
-

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

-
-
+
+
+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic

+
+
+

Harnessing the Power of API Specifications for Robust Microservices  Modern microservice architecture hinges on precise and dependable communication between services. This is where API specifications serve as the linchpin, establishing clear, executable contracts that dictate how services interact. With advancements in AI, we can now take these specifications and seamlessly transform them into running applications. […]

+
+

Build Apps from API specs using AI: Self-Correcting Contract-Driven Agentic Workflows with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
-

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

-
-
+
+
+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+
+
+

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic  A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates

+
+

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​ Read More »

+
+ +
+
-
+
-
-
-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

-
-
-

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven

-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

-
-
+
+
+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+
+
+

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment.  In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven

+
+

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development Read More »

+
+ +
+
-
+
-
-
-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

-
-
-

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

-
-
+
+
+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

+
+
+

Exploring the Strengths and Weaknesses of Automated API Development  Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating

+
+

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​ Read More »

+
+ +
+
-
+
-
-
-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

-
-
-

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

-
-

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

-
-
+
+
+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​

+
+
+

Understanding the Shortcomings of gRPC and How Contract Testing Can Bridge the Gap  In the ever-evolving world of API design, development, and testing, the pursuit of a seamless developer experience (DevEx) remains a constant. This article sheds light on some of the overlooked pitfalls of gRPC, a popular choice for its performance capabilities and type-safe

+
+

gRPC Flaws​ – The Illusion of Safety & Frustrating DevEx in Proto3’s Type-Safe Contracts​ Read More »

+
+ +
+
-
+
-
-
-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

-
-
-

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

-
-
+
+
+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

+
+
+

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development  APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of

+
+

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through  Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic Challenge – winners announced!

-
-
-

The Specmatic challenge is over and we are pleased to announce the winners! Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes! You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give

-
-

Specmatic Challenge – winners announced! Read More »

-
-
+
+
+
+

Specmatic Challenge – winners announced!

+
+
+

The Specmatic challenge is over and we are pleased to announce the winners! Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes! You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give

+
+

Specmatic Challenge – winners announced! Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing using gRPC Specs as Executable Contracts

-
-
-

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

Contract Testing using gRPC Specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing using gRPC Specs as Executable Contracts

+
+
+

Transform your gRPC API specs into executable contracts in seconds Now you can easily leverage your gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

Contract Testing using gRPC Specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC

-
-
-

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

-
-

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

-
-
+
+
+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC

+
+
+

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of

+
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC Read More »

+
+ +
+
-
+
-
-
-
-

API Resiliency and Contract Testing for GraphQL

-
-
-

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

-
-

API Resiliency and Contract Testing for GraphQL Read More »

-
-
+
+
+
+

API Resiliency and Contract Testing for GraphQL

+
+
+

Transform your GraphQL API specs into executable contracts in seconds Now you can easily leverage your GraphQL APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you,

+
+

API Resiliency and Contract Testing for GraphQL Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -1041,7 +1150,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/introduction-to-contract-driven-development-with-specmatic/index.html b/updates/introduction-to-contract-driven-development-with-specmatic/index.html index c50aa0ba6..465867ef0 100644 --- a/updates/introduction-to-contract-driven-development-with-specmatic/index.html +++ b/updates/introduction-to-contract-driven-development-with-specmatic/index.html @@ -3,8 +3,8 @@ - -Introduction to Contract Driven Development with Specmatic - Specmatic + + Introduction to Contract Driven Development with Specmatic - Specmatic @@ -15,6 +15,7 @@ + @@ -60,36 +61,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Introduction to Contract Driven Development with Specmatic

+ + + +
+ + +

Introduction to Contract Driven Development with Specmatic

-
-
+Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + +

Transcript

+ + +

Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have one or many domain services. Once the domain service gets back with a response, we want the BFF to log the message onto a Kafka topic, which allows our analytic server to pick it up and do its thing. The BFF would get back to the application with its response. In order to allow the app and the BFF to independently develop and deploy, we would like to capture the contract between them in an OpenAPI specification. This would capture things like what is the URLs that are being exposed by the BFF, the request parameters, the mandatory optional parameters, and also what is the response that the BFF would give to this request, which means what are all the HTTP statuses that it can get back with, also the schema of the response. Similarly, between the BFF and Domain Service, we would have the OpenAPI specification.

+ + +

Now, for Kafka, we would capture the specification in something called AsyncAPI, where you can describe what are all the topics that are available and the message formats of those topics. Now, let’s jump into a demo. All right, to start this demo, let’s first start our domain service, which is the Order API. It’s a spring boot app, so I’m just going to get the app started. And then here we have the Domain Service. We need to start Kafka. Let me go here quickly, and you will see here that I’m using Specmatic to stub out Kafka. We’ll get into this detail a little bit later. Let’s get this kicked off, and you’ll see that Specmatic is starting this. It figured out which ports are available. As you can see now it’s listening to messages on this topic, product queries. Let’s also start our BFF layer. Again, a spring boot application which we’re going to kickstart with a gradle command. There we have the spring boot application also started. Let’s make sure all of these things are wired up and working correctly. I’m going to try and make a curl request. I expect when I make this request, one message to come back.

+ + +

And sure enough, yes, we got one message. This means that all our services are now wired up correctly. With that, we are ready to get started. I have this Open API specification which describes my BFF layer. It’s got a bunch of paths here. There is slash products, which is I can make a post request to create a new product. It can respond with the 201, 400, 503. I also have a find available product which basically takes a query parameter and also a header parameter called page size to get me back a list of products. I can also create orders and so forth. I’m going to use Specmatic plugin, which is built into VS code to run the contract test. There we go. Here you will notice that I am pointing to the BFF API specification, which we just looked at a minute ago. I’m also pointing to where my application is running. It’s running on port 8080. With that, let’s run these tests. Notice that I’ve not written a single line of code at this point. When I run this test, it’s going to go ahead and generate. It’s executing seven contract tests for me.

+ + +

Where did it find these contract tests? It basically figured out from the OpenAPI specification. Let’s zoom this in. As you can see, it’s made a request to slash products, and it figured out that I can send 1.77 for inventory because it’s a type integer. There is type gadget and then name. It’s generated again a random value and the server responded back with a 201 and gave an ID 4. This we are then saying that this was a successful test. Similarly, it’s made another request and this time you will notice that instead of here, we used Gadget, it’s used type book. How is Specmatic figuring out that it needs to send these things? Let’s quickly go to the OpenAPI specification and look at this section. So you will see here for type, we have defined it as an enum, which is Gadget, Book, Food, Order. And so what Specmatic does is it takes that and iterates through that, and you will see that it’s made a request for each one of these types. And of course, it’s made request now to slash find available products and it’s got a list of products back. It’s validated against the specifications response and it said, yes, this makes sense.

+ + +

This is all matching and hence this test has succeeded. It’s also try to make a request to find products with type string and it’s got back a 400 error. We’ll get to it in a minute why this happened. Finally, it’s try to make a request to orders with certain product ID and essentially it’s got back a 404, which means this does not exist. One other cool feature of Specmatic is it also shows you an API coverage. Very quickly, you can see what all paths exist within the application, both in your API specification and in your application. It then reports whether it was able to cover it or not. In this case, it found /find available products. There is a get request only on it, and it has 200, 400, and 503. It was able to make two get requests, and those two were covered, but was not able to make any request to 400 or 503. Similarly, it also found a slash health point, which it’s missing in the specification, which means it found it in the application but not in the specification. Wait a second. How is Specmatic figuring out that slash health exists in the application but not in the specification?

+ + +

So here we use an actuator, which in Springboard comes built-in. Using the actuator, you can figure out what all paths are available. This can be very handy if you want to do any observability. So Specmatic leverage is the same thing and tries to figure out, Okay, I found a slash health endpoint on the application, but I do not see that in the specification. Similarly, it also found a slash orders in the application and it found that missing. However, you can notice that there is what was supposed to be orders. It looks like a typo, which is there in the specification but not in the application and hence it’s saying it’s not implemented similarly slash products. This is cool because now very quickly you get a quick overview of what is there in your specification and also what is there in your application. With Specmatic plugin, we were able to figure out and even execute some tests. Now, let’s try and clean up this and try and get a better coverage. The first thing I want to do is I want to fix this typo in the specification so that we can make it work. Let’s go to right here.

+ + +

We see that there is a typo, so I’m going to try and fix that typo. With that, let’s run the contract test again right here. Specmatic is going and running these contract tests again. Notice this time, it is basically say, slash orders. Yes, it is available in both places, and it did, in fact, cover it. This health endpoint is interesting. I actually don’t want this health endpoint to be in my specification. It’s purely for monitoring and observability. What I’m going to do is I’m going to use one of the features we have here where we can exclude certain health endpoints or other kinds of health points. Let’s, with that, run this again. Specmatic is going to go ahead and execute all of these tests. This time, you will notice that slash health is not being reported, and we’ve been able to now achieve a 33 % coverage on all of our paths that we have. Thirty-three is great. We have the positive cases, the 200 cases covered. None of the 400 or 503 cases are covered at this point. And also we have two failing tests, as you can see. Out of the total seven tests that is generated, five are successful and two are failing.

+ + +

Why are the two failing? Because Specmatic has tried to guess certain data and generate that, but that data does not exist. For example, here, we try to create an order with a product ID 674, but this 674 is not actually a valid ID in our database. There isn’t a product with 674 in the database. At this point, what we would need to do is provide examples in our specification so that Specmatic can guide its generation of tests. We’re going to use our plugin to generate examples. I’m going to go ahead and kick that off. You will see here, we are leveraging GPT-4 to generate these examples. All right, there we go. As you can see, Specmatic has been able to leverage GPT-4 to generate relevant examples for our context. Here we can see the difference, what was before and after. In the products, it’s generated an example of a successful request it can make with iPhone, Gadget, and Hundred as the inventory, which makes sense. Similarly, it’s said, Okay, I should get back ID 1, which is a valid ID in our case. This is several different examples, and you can also notice that it’s generated another example for the GET, where we are saying that, When you get, I should get back a product with iPhone, ID 1, a type gadget, and even a little description saying, Latest iPhone model.

+ + +

Using GPT allows us to generate really relevant examples. I could have manually written all of this, but you could actually generate a lot of these examples leveraging GPT, so why would you want to do this by hand? All right, with that, I think we can close this comparison window. Now, let’s go back and run our contract test. Actually, I’m going to just reuse this window. Let’s clean this and run this. Here we go again. You will notice that this time, Specmatic has generated only three tests, which it used to generate seven tests, but now it’s down to three tests. The reason is now, Specmatic is going to use only the examples that you have provided and use those to generate the tests. In this case, now you can see that we’ve got all our tests passing. We don’t have any more failures. Of course, we have one-one-one of each of these covered, so we’re still maintaining the 33% coverage. The question is, can we do something better? Yes, in fact, let’s go ahead. What I’m going to do now is I’m going to use this feature called Generative Tests. What is generative tests? Let me quickly run this, and then as the test run, I’m going to explain to you what generative test does.

+ + +

I’m going to clear this out so that you can see what’s going to happen. Let’s go ahead and run this. Wow! You can see now, Specmatic is generating 41 tests. You can see as things are scrolling by, there are some positive, some negative scenarios it’s going to generate. It’s going to generate a whole bunch of different tests and they are going ahead. And wow, you can see that we have 41 tests that are generated, only six succeeded, 35 failed. All right, so how did Specmatic generate 41 tests? We took the inspiration from two things here. One is property-based testing and mutation testing. Let me explain each of these. What is property-based testing? In our case, we understand that we can look at the OpenAPI specification. If a certain field is or a parameter is marked as mandatory, then we know that’s a property of this API that for this particular request, this particular field or parameter is mandatory, and we have to send that. And so if you don’t send it, then you would expect a 404 or some bad request, 400 bad request to come back. And so we can think about these properties of the OpenAPI specification or AsyncAPI specification and leverage that to help us construct a set of tests for us.

+ + +

Then also to build on that idea, we can look at mutation testing where essentially you can mutate the code and then send requests to the code and see if the test that we’re passing earlier starts to fail now. Instead of doing that exact same thing, we took inspiration from it and changed the idea a little bit where instead of mutating the code, we mutate the request. For example, if something is mandatory and when we send it, we get a 201 back. But in this case, if we don’t send something, then we expect 400 to come back, which is some examples you will see here that we have generated. That’s the combination of property-based testing and mutation testing, which we call as generative tests. That’s what has allowed us to generate these 41 tests for you. However, these 35 tests are failing. Let’s understand why they are failing. They’re saying key-named message is in the response, but not in the specification. Response body message. Why is that happening? Let’s look at one of these requests that it sent. It sent this request to order with some value and essentially count should have been a number. But in this case, we have mutated the value and we have sent, instead of a number, we have sent a string to just make sure that your code can handle this and does not end up in an exception.

+ + +

And what we see is this negative scenario has failed because the key named message, which is this guy, is not there in the specification. So what is there in the specification? Let’s go to the specification here. And this is the bad request. So as you can see, we have timestamp. Yeah, sure enough, we have status. Okay, sure. We have error. Cool. But here in the specification, we have paths. However, the actual response is a message. Yeah, that makes sense. This looks like, again, a mistake in the specification. This should have been a message. So let’s update the specification with that, and let’s clear this out. And let me run the contract test again and see what happens this time. All right, it’s generating the 41 test again. Cool, and like you can see now, we have finished and we have been able to successfully generate all the tests and all the tests are passing. Wow, this is pretty cool. Let me look at the API specification and you can see that now we have 67 percentage on all three paths. You’d also notice some of the 400 cases are being covered, which is pretty cool.

+ + +

We now are covering 200 and we are covering 400. As you can see here, let’s look at some of these just to understand what it’s done. So in the beginning, there are a whole bunch of positive scenarios. As you can see, these plus positive scenarios. And then these are the standard ones that we’ve seen before. Let’s scroll down to a negative scenario. So here we have a negative scenario where a name, which is a mandatory and a non-nullable field, we have sent, Specmatic has sent a null, and it’s of course, got a 400 bad request, which is expected in this case. And hence we are saying, Yes, this scenario has succeeded for us. This negative scenario has succeeded. Our application knows how to handle this correctly and give back a 400 response. And of course, we will iterate through all the different enum types and have a test for each one of those. We’ll also see a few other interesting examples where name is sent as 470, name is a string, but we’re sending a number to see what happens and ensure the application is throwing a 400 back, and that also has helped us succeed this test.

+ + +

So like this, Specmatic figures out and sends different combinations. Again, you can see here, name is sent as a boolean value. And similarly, you’ll also see some of their inventory. We play around with inventory and see if that is being handled. Here you can see type was sent as null and so forth. These are all valid examples of negative tests to make sure that the application can handle all of that. That’s how we arrived at these combinations of 41 tests and we were able to validate both positive and negative scenario. Let me just quickly recap. We started, we had an OpenAPI specification, we got the application running, and then we used Specmatic plugin to generate tests for us. We did not write a single line of code. Just with the specification, it was able to generate seven tests for us. Of course, five tests were passing and two were failing because the examples were missing. But when we did that, we also got an API coverage and we figured out there were some mismatches between the specification and the application. We were able to fix those and we were also able to ignore the slash health endpoint, which we didn’t want to cover in the specification.

+ + +

We now had tests working. However, the examples were missing. Again, we use Specmatic and leveraging GPT-4. We were able to generate examples for us. With that, we were able to bring down the test count to three specific examples that we were given, and all those three tests were passing. Then we turned on Generative Tests, and with Generative Tests, we were able to generate 41 tests. Initially, quite a few of those tests failed because again, there was a mismatch in the specification. But once we fixed the specification, we were able to see all the 41 tests pass, and now we have pretty good coverage of 67%. However, I’m still worried about this 503. We do not seem to cover this. For that, let’s look at another interesting aspect of Specmatic. If we go back to our slide over here, you would see that we have a domain service running, basically catering to the request that the BFF is sending. In this case, we have a real domain service running and the BFS is connecting to the real domain service. Now, I want to simulate a case where for those 41 tests that I have, I want to make sure that the domain service is responding back with the valid responses like it’s doing now.

+ + +

However, I want to add another new scenario. In that scenario, I want to make sure that domain service does not respond back in time. Let’s assume that my BFF has a timeout set for three seconds to receive a response back. But BFF, when it contacts the domain service, the domain service takes more than three seconds, let’s say, five seconds to respond back. In that case, I would expect my BFF to give me a 503 back. The service is unavailable and I really can’t do anything. I want to now test this scenario. How do you think we can do this? In the case that I want the 41 test that I already have to respond within the three seconds timeout, but for only the 42nd scenario, I want the domain service to not respond back in time. Well, you could be sitting there watching these tests run, and when the last scenario is about to run, you could shut down the domain service and make sure that it times out and you can simulate this. But how would you do this in your CI pipelines? And also it’s not practical to be able to do this.

+ + +

So for that, we do have a feature in Specmatic where we will be able to simulate these. But for that, first, I want to not rely on an actual domain service. Instead, I want to stub out the domain service and then do all kinds of fault injection, different scenarios. I’d have full control over that. So let’s see how we can stub out the actual service, the domain service that is running with a Specmatic stub. The good news is that if you already have an OpenAPI specification for this, you could leverage that. But it may also happen that you don’t have an OpenAPI specification already for the domain service. Don’t worry, Specmatic has a feature called proxy through which we will be able to record the interactions between the BFF and domain service and generate an open API specification along with the request response, the stub data, what we call, so that you can replay all the requests exactly the same way back. This is what we call a service virtualization. Let’s look at how that can be done. Let me quickly jump here. Let’s clear this out. I’m going to start a proxy server.

+ + +

What I’m saying is, hey, it’s Specmatic. This is my target, localhost 8090, which is where the domain service is running, and record all of the interactions in a Recordings folder for me. I’m going to kickstart that. With this, Specmatic says, Okay, I have now a proxy server running on 9000, and that is basically channelling all requests going to 8090. Perfect. Also here in the application properties, you will notice that the OrderAPI, which is our domain service, is running on 8090. Now we wanted to say, Hey, not 8090, go to 9000, where our proxy server is running so that we can channel all the requests. I make that change and let me just quickly restart my BFF layer so it will pick up this change. There we go. It is started. Now, let’s go back to our contract test and rerun the contract test. I’m just going to run the contract test again. You’ll see it’s going ahead and rerunning again those 41 different scenarios. What you will see here, if I go to the proxy, it is now recording all the traffic that is going through the requests that are going through and the response that is coming back.

+ + +

Looks like it stopped, which means our 41 tests have run and all of them are successful. Notice that the application is none the wiser now. It has just behaved the way it was behaving earlier, except that we have routed all the traffic through this proxy server. Let me shut down this proxy server, and when I shut down the proxy server, you will notice that it has generated the OpenAPI specification for the domain service, and it’s also generated out 13 stubs. You’ll notice that we had 41 tests running, but only 13 stubs have been generated. This is why we call this as Intelligent Service Virtualization, which means it is not just a dumb recording of every request. It’s actually looking at those requests and saying, Yeah, these two requests are similar, I can generalise it, and then it distills it down to these 13 unique requests. Let’s go to the Recordings folder and let’s see this OpenAPI specification that is generated. It’s generated an OpenAPI specification for slash products and it says, okay, there is a get on this which takes parameters in the query called type. It has a bunch of other parameters that it’s expecting.

+ + +

Then it sends back a response and it’s also nicely reused the response by capturing it over here. You can jump over here and see that ID, inventory, name and type is what the response comes back. This, Specmatic has now recorded several different APIs, endpoints for the domain service and also generated the stub data. We can look at any one of the stub data and see what’s in it. It says, okay, HTTP request slash products, a POST request, and it’s got this in the header, it’s got this in the body, and then the response came back with a status 200 and a ID-37 back. That is just a simple request-response pair that is captured as a stub files, and each of them will have some unique flavour of the request response. So perfect. With that, now I have the OpenAPI specification for the domain service. I also have some stub data for it. And with that, I should be able to tell Specmatic to run now Specmatic in a stub mode and point it to the generated OpenAPI specification saying, Use this generated OpenAPI specification as a way to generate a stub out of it. Again, you’re not writing any line of code here to generate a stub, and you’re actually referring to an open API specification to generate the stub.

+ + +

This is a big deal because most often people have to write a lot of code to generate these tubs or use some tools to generate these, and they can very quickly drift away and go out of sync. But in this case, because we will be referring to the same OpenAPI specification that the provider is also using to generate contract tests, they don’t drift away. They point to the same single source of truth, which ideally exists in a central Git repo. So anyway, with that, let me quickly run this, and you will notice that it will go ahead and load all the stubs up and say, Okay, I have now got a stub server running for you at port 9000, and you can go ahead and use it. Just to be sure that we are not fooling ourselves, I’m going to go ahead and here in my API, the domain service, order API, I’ve killed it. Now there is no longer the service running and we only have a proxy running at this stage. What do you reckon when I run these tests? What do you expect to see? Well, I expect to see that everything works as before and there is no surprises.

+ + +

Let’s run the test and see what happens now. I expect that the application would be none-the-wiser. It’ll still go ahead and generate those 41 tests and you would also be able to see at the proxy, there are requests that are coming in and the proxy is responding to all of those requests. There we go. We have all 41 tests that have succeeded. We don’t have a downstream service running the domain service. We are able to completely work off a stub that is generated purely from the OpenAPI specification by Specmatic, again without writing a single line of code. This is why we say this is a no-code solution. Now, of course, we still have not done anything to cover the 503 case because so far all we have tried to do is essentially stub out the downstream service so that we have much better control now and we can simulate the different conditions. With that, let me jump in and show you how we will be able to generate a 503 response in this case. We want to basically go to the generated spec. But before that, actually, let me add another example here which basically says any time I make a GET request for, let’s say, the type other, I want it to generate a response with basically timeout and that would result in a 503.

+ + +

Let me find the relevant section, so Find Products. We have an example over here which is a success example. I’m going to add another example for timeout. That’s just a name that I’m giving. And that should be value 100, really does not matter. Similarly, for query, I’m going to add, for the query parameter, I’m going to add another example, which I’m going to use as other. Anytime I send other in the query parameter for slash available products, I expect, let’s go to the response here real quick. This is my 503 bad request, so I’m going to go here and I’m going to give an example. So examples, and you can see GitHub Copilot has already guessed that this is the response that you would want. Timeout, a 503 service unavailable because of a timeout. And so with that example in, now I have added another example in my OpenAPI specification, which is essentially expecting any time I send a query parameter as other to get a 403. To make this possible, we will have to go to the generated test data. Let’s look at one of the examples. Here, we have slash products, a GET, and then we are responding back with some valid response.

+ + +

I’m just going to go ahead and duplicate this. I’m going to make a copy. I’m just going to rename this to stub timeout. In this case, instead of gadget, now I want to put other. Here, and I’m going to go ahead and add a new property which essentially says delay the response to five seconds. Whenever you get a request for slash products, get for a type other, then delay the response back in five seconds. You will notice that as soon as we have updated the stub, Specmatic proxy automatically reloads it, so we have this loaded now. With that, let me quickly go back to our contract test. Now let’s run the contract tests again and see what happens. This time I would expect to run 42 tests, the one new scenario that we’ve added for the timeout. With that, it’s going ahead and running all the tests. And sure enough, as you can see, we have 42 tests that ran. All 42 tests succeeded. Let’s look at this. You would see here that we’ve got 100% API coverage for the slash find available product. You’ll also notice that a 503 case is now covered. How did this happen?

+ + +

This happened because we were able to simulate a timeout and that resulted in a service unavailable response. Let’s quickly look at where did we generate the 503. You will notice here I made a request to find available products with type other. Whenever we send with type other, we expect the downstream service to basically result in a timeout, and which again, this BFF layer will propagate as a 503 service not available. We’re also validating that the 503 is matching the schema that we have for 503. So with that, we have been able to use Specmatic to generate the contract test. We’re also able to stub out downstream services and do fault injection and other kinds of negative scenarios because we have control over the downstream service through a stub that we generated. And now we are able to get a fairly high degree of confidence that our specification is in fact in line with the actual implementation. So that is, in a short demo, what the power of Specmatic is. Also, I talked about later on, I’ll show you how we were stubbing out Kafka. So here, if I go to this, you will notice that all these requests are coming in, the messages are being posted onto the Kafka topic.

+ + +

Essentially, this is a Specmatic stub that is running because we don’t really want to have a real instance of a Kafka broker running on this laptop. While you can certainly do it, there will be inherent latency and other kinds of things that you have to deal with. This certainty that you have for your contract test, you would not be able to get. In this case, at the end of this demo, what we’ve been able to achieve is stub out both the dependencies that the BFF layer has, so the domain service we were able to stub out, and we were also able to stub out the Kafka dependency that this service has. Now we have full control over our BFF layer, and we can contract test it, make sure that it is in line with the specification. I’ve been showing you the demo of running these contract tests from the plugin. However, I just want to make sure you can also understand that you can run all these tests from a code. All these changes that we’ve made can be checked in and can be run by other developers on their local machine as well as by your CI pipeline.

+ + +

Also to run that, Specmatic can generate this one-time contract test code where we essentially just need to configure where our application is running, where our step server is running, where the Kafka mock is running. You can then specify whether you want generative test on or off, and pretty much specify the location of where the stubs are available and start the application. Let me quickly run this test now for you. As you can see, it is kicking off and running these tests. And there we have the 42 tests, the same test that we saw running earlier. All those 42 tests are now running from within my IDE. Same thing can run from the CI pipeline as well. This way you can ensure that these tests are continuously run by other developers and also by your CI pipeline. Cool. That was a quick live demo. Let’s just quickly recap. We have the BFF here, which is a system under test. We were able to use Specmatic contract test to use the OpenAPI specification to generate the test. We were also able to stub out the domain service dependency through a Specmatic HTTP stub, which was based off the OpenAPI specification, of course.

+ + +

We were also able to stub out the entire Kafka piece with a Kafka mock that was generated using the AsyncAPI. What that essentially did was generated an in-memory broker for us and created the topic that was there in the AsyncAPI specification. We were also able to do schema validations of whether the messages that were posted on the topic were actually schema valid as per the AsyncAPI. Wee initially, we set expectations through those JSON stub files that you saw on the HTTP stub. We were also able to set expectations on the Kafka topics. Then we generated the request from Specmatic to the BFF layer, which went through the stub. The stub responded back. The BFF layer then put the message on the Kafka topic and sent the response back. Whenever the response came, Specmatic was able to validate that the response was in line with the response schema and data types that were specified in the OpenAPI specification. It was also able to then verify whether the number of messages that were posted on the topic and the schema of those messages that were posted were, in fact, as per the AsyncAPI specification.

+ + +

That is, in a nutshell, how we are able to contract test the BFF layer and make sure that it is in line with the specification and interacts with its downstream dependencies as expected and as specified in their respective specification. If you were to do this without Specmatic, typically you would have to do continuous integration. The consumer would do continuous integration with some a stub that they would have hand-created on their own, and things would all look good in their local environment and the continuous integration environment. Similarly, the provider would do the API testing locally and on the CI. However, when they came to the integration environment, they would realise that maybe there are some disconnects and that would cause problems in integration and the entire environment can become stable. And this also blocks your path to production. And the later you find these issues, the more expensive they get. So the whole idea with contract-driven development is to shift this left and give that feedback as early as possible, ideally on the developer’s laptop. We do this through Specmatic, where we take an OpenAPI specification or AsyncAPI specification and we generate a stub for you, which is service virtualization.

+ + +

The consumer can now work with this stub as if it was talking to the real thing. We take the same very specification because that’s a single source of truth, and generate tests of that to make sure that the provider is in fact adhering to the specification. This is what ensures that they don’t drift away and they both can independently develop their stuff while being completely in sync. All right, so having a single source of truth is extremely important because even though many teams agree to an OpenAPI specification, but they may miss updating it, or they may not refer to the current version, and you may still end up implementing things in a wrong way and have an integration issue at a later point in time. So what we try to do is we put all of this in a central Git repo. So we take the OpenAPI specification, we create a central Git repo, and we go through a pull request process where we do linting to make sure that the OpenAPI or AsyncAPI specifications are as per the standards that we have agreed. We also then do a compatibility test to make sure that when you’re making any changes to these specifications, you’re not accidentally breaking backward compatibility.

+ + +

So how does this backward compatibility thing work? So what Specmatic does is it basically takes the new version of the specification and it picks the old version of the specification from the Git repo. And notice earlier I explained that Specmatic can take the very same specification and run that as a stop in service virtualization mode and also run it as tests in a contract testing mode. So what we do is, and this was almost an accidental discovery, I would say, where we take the new specification and we run that as a stub, and we take the old specification, we run that as a test. The old specification will make API requests to the new specification that’s running as a stub. As long as all the old tests pass, then you know that your new version of the API specification is backward compatible. That’s what happens. A real test get executed. It’s not a simple text comparison. These are real tests that get executed. Then once the tests are passed, someone would review and merge this. This will ensure that your single source of truth, which is the central contract, always stays up to date. All right, to just summarise, Specmatic then takes the OpenAPI specification.

+ + +

The consumers can run their test locally by using contract as stub or service virtualization. The providers can take the contract tests and use Specmatic to generate the contract test to validate whether their implementation is in sync with the specification. The same thing can be leveraged in the CI, where they are all referring to the single source of truth, which is the OpenAPI or AsyncAPI specification on both sides. And when they come to an integration environment, you do not expect to see any surprises and you can get to production as quickly as possible. That’s, in a nutshell, what we call Contract-Driven Development.

+ + +

We have recently launched Specmatic Insights, which allows teams to visualise the service dependencies in a very visual manner where you can take all the data that is generated by running these contract tests in your pipeline and have this visualisation built out of real data and then see which service is dependent on which other service, what endpoints is it dependent on. And do you have a single point of failure? Do you have a choking point in your architecture? You also be able to drill down into a specific API and look at what are all its consumers, what are its dependencies, and also what type of dependencies it depends on.

+ + +

Is it a HTTP dependency? Is it a Kafka dependency? You’d also be able to monitor the overall coverage of how things are improving in terms of your CDD adoption. How many endpoints do you have in the central repo? How many of them are being consumed both by the provider and the consumer? And what is the overall API coverage? Is it trending up or trending down? So these insights can help you improve your CDD adoption in your organisation. And just to recap, we can support AsyncAPI, and there we can use JMS. If you have JMS, then you can mock that out. You can also use it for stubbing out databases, the JDBC stub. You can use it for stubbing out readers, and many more such capabilities exist. So do check us out on Specmatic. In. Thank you.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -980,7 +1190,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/jdbc-stubbing-with-specmatic-contract-testing/index.html b/updates/jdbc-stubbing-with-specmatic-contract-testing/index.html index aea453d3c..44d01bf67 100644 --- a/updates/jdbc-stubbing-with-specmatic-contract-testing/index.html +++ b/updates/jdbc-stubbing-with-specmatic-contract-testing/index.html @@ -3,8 +3,8 @@ - -Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing - Specmatic + + Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing - Specmatic @@ -15,6 +15,7 @@ + @@ -57,36 +58,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+ + + +
+ + +

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Context

+ + +

To test our applications effectively on our local machines and in lower environments such as CI pipelines, we often need to isolate them from their database dependencies to make sure that the test environment is simple to set up and our tests themselves are quick to run. A few popular options that come to mind to achieve the same include in-memory databases and containerised databases. However, there are limitations to each of these approaches.

+ + +
  1. In-memory DBs – They are database simulators and usually cannot handle syntax and data types that may be proprietary / vendor specific to your database. Legacy applications with stored procedures may be even harder to deal with.
  2. + + +
  3. Containerised DBs – They are real databases and thereby also involve significant effort initially to achieve parity with your production database in terms of schema and data setup (Especially in legacy applications which lack automated DB deployment mechanisms).
+ + +

To overcome these limitations we need a “Database Stub”.

+ + +

Solution

+ + +

Specmatic JDBC Stub is a completely wire-compatible setup that has none of the above limitations. It is able to seamlessly stub a JDBC datasource because of which your application thinks it is talking to a real database. This helps in creating a realistic test environment that can be quickly spun up in-memory.

+ + +

Key features

+ + +
  1. Eliminate Database Dependency: JDBC stubs allow us to isolate APIs from their database dependencies, enabling us to test without the need for a complex DB setup. By switching out the data source with a Specmatic JDBC stub, the API can communicate with the stub instead of the actual database.
  2. + + +
  3. Define / Record and Replay Expectations: With Specmatic JDBC stub, we can set expectations for queries and their responses. These expectations can be written by hand or recorded based on actual interactions between the API and a real database. This allows you to verify that your application is only interacting with the database as intended by you.
  4. + + +
  5. Stub vendor specific SQL syntax – Since Specmatic JDBC stub operates at the level of abstraction of a DataSource, you can effectively stub all types of interactions including stored procedure calls.
  6. + + +
  7. Blazing Fast In-memory Setup – Super charge your tests (component, contract and API tests and more) with Specmatic’s fast in-memory JDBC stubbing capability that speeds up your overall test execution time thereby making for a great Developer Experience.
+ + +

By leveraging Specmatic JDBC stubs, we can effectively test APIs, reduce dependencies, and ensure the reliability and integrity of our applications.

+ + +

Check out the sample code

+ + +

Sample project: Manual configuration
Sample project: Spring auto-configuration

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + +

+ + +
Jdbc stubing production mode jdbc stubing test mode Redis Stubbing with Specmatic Contract Testing.
+ + + + + +

Benefits of Specmatic JDBC Stub: Replacing Real Data Sources & Enhancing the Testing Process

+ + +

At the core of the testing process lies the ability to isolate the application from its database dependency. Specmatic JDBC stub achieves this by replacing the real data source with a Specmatic data source. By doing so, the API under test communicates with the Specmatic JDBC stub instead of the actual database. This allows developers to run different types of tests without the hassle of depending on a complex database setup. The Specmatic JDBC stub acts as a drop in replacement for  the database in your test environments, ensuring smooth communication and accurate test results.

+ + +

Setting Expectations with Specmatic JDBC Stub for Contract-Based API Testing

+ + +

To effectively use Specmatic JDBC stub, the first step is to set expectations with the stub regarding the queries that it can expect and the corresponding data it needs to respond with. These expectations can be manually written or recorded based on actual interactions between the API and a real database. Once the expectations are set, the real database is no longer required in the testing setup.

+ + + + + +

Code walkthrough: Specmatic JDBC Stub for Testing

+ + +

Let’s delve into a concrete example to illustrate the power of the Specmatic JDBC stub. Consider an application that provides a wrapper for managing product entities. In its production configuration, it relies on a real database for data storage.

+ + +
A screen shot showcasing Specmatic's JDBC stubbing capabilities to liberate from database dependencies.
+ + + + + +

However, for testing purposes, we want to isolate the application from the actual database. By disabling the data source auto-configuration, the application loses its ability to communicate with the real database.

+ + +
A code editor with JDBC Stubbing capabilities.
+ + + + + +
Using Specmatic for JDBC Stubbing to break database dependencies in a web browser screenshot.
+ + + + + +

Instead, we configure the Specmatic JDBC stub as the data source for testing. This is achieved by adding the Specmatic JDBC dependency and setting up a bean for the data source, specifying the port and directory where the expectations are stored.

+ + +
Leveraging Specmatic for JDBC Stubbing in a code editor screen of Adobe Acrobat.
+ + + + + +

Seamless Contract Testing with the Specmatic JDBC Stub and OpenAPI Specification

+ + +

With the Specmatic JDBC stub in place, we can now run contract tests based on the OpenAPI specification of the API. These tests make HTTP requests to the application, which in turn communicates with the Specmatic data source.

+ + +

The data source responds with the predefined data that was set up as part of the expectations.

+ + +
Leveraging Specmatic for JDBC Stubbing in a code editor screenshot.
+ + + + + +

When Specmatic JDBC stub receives queries that it is not expecting, it throws errors to indicate the same thereby giving us feedback when our application code is making any additional calls to the database.

+ + +
A screenshot of Specmatic, a Java script editor for breaking database dependencies by leveraging JDBC stubbing.
+ + + + + +

From the application’s perspective, it appears as if it is interacting with the real database. The application processes the data and returns it to the Specmatic contract test, which then validates if the response conforms to the schema described in the OpenAPI specification.

+ + +

This seamless integration allows developers to confidently test their applications while eliminating the need for an actual database.

+ + +

The Benefits of Utilising Specmatic JDBC Stub for Testing Applications with Database Dependencies

+ + +

In conclusion, Specmatic JDBC stub provides a powerful solution for testing applications with database dependencies. By replacing the real data source with the Specmatic data source, developers can easily isolate their applications from complex database setups in their test environments and perform comprehensive tests including API, contract tests and more. For example, with Specmatic’s ability to generate contracts from OpenAPI specifications (API specifications as contract tests), developers can verify the correctness of their APIs without the need for an actual database instance.

+ + +

By leveraging Specmatic JDBC stub, developers can streamline the testing process, increase test coverage, and ensure the reliability and stability of their applications.

+ + +

+ + +

Sample project: Manual configuration
Sample project: Spring auto-configuration

+ + +

Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Contact us to join the private beta.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1007,7 +1277,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/jms-mocking-with-asyncapi-using-specmatic/index.html b/updates/jms-mocking-with-asyncapi-using-specmatic/index.html index 66f31bba4..758045773 100644 --- a/updates/jms-mocking-with-asyncapi-using-specmatic/index.html +++ b/updates/jms-mocking-with-asyncapi-using-specmatic/index.html @@ -3,8 +3,8 @@ - -JMS Mocking with AsyncAPI using Specmatic - Specmatic + + JMS Mocking with AsyncAPI using Specmatic - Specmatic @@ -15,6 +15,7 @@ + @@ -58,36 +59,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

JMS Mocking with AsyncAPI using Specmatic

+ + + +
+ + +

JMS Mocking with AsyncAPI using Specmatic

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Key features

+ + +
  1. Mocks a real JMS server so that clients can communicate with it seamlessly.
  2. + + +
  3. Validates the messages that it receives against the schema defined in the AsyncAPI specification.
  4. + + +
  5. Provides the ability to set and verify expectations on it.
+ + + + + +

Check out the sample code

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-jms
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + + + + +

Overview – how Specmatic can be used to mock JMS using AsyncAPI

-
+ + + +
+ + + + + +

Let’s take the example of a consumer which makes a request to an application. The request is received by the controller, which in turn invokes the service layer. The service layer fetches data from a domain service or an HTTP dependency, and then drops the message on to a JMS queue – something like Active MQ. Finally, the service layer responds back to the controller, which in turn responds back to the consumer. Now, to test this application in isolation, we take an AsyncAPI specification which describes the JMS queue and the schema of the messages that it is expected to receive. And we mock it out using Specmatic’s JMS mock. With the JMS mock now in place, we can run contract tests against the application. 

+ + +

First, we set expectations on the JMS mock, describing the messages it is expected to receive. Then, we also set expectations on Specmatic’s HTTP stub, which uses the OpenAPI specification for the application’s HTTP dependency or the domain service. If you want to learn more about contract tests and how to stub out HTTP dependencies using OpenAPI specifications and Specmatic, check out this video.

+ + +

Next, Specmatic uses the application’s OpenAPI specification to run contract tests against it. Every contract test results in a request being sent to the application, which is received by the controller. The controller invokes the service layer, which in turn fetches the data now from Specmatic’s HTTP stub. And then drops the message on to Specmatic’s JMS mock. When the JMS mock receives the message, it validates the message against the schema defined in the AsyncAPI specification. If the message does not match the schema, then it will fail the test. The JMS mock has an in-memory active MQ broker, so the service layer can communicate with it quite seamlessly just like it would with a real-time JMS queue in production.

+ + +

Finally, the service layer responds back to the controller, which in turn responds back to the contract test. When all contract tests are executed, Specmatic calls the JMS mock to validate the messages that it has received.

+ + + + + +

Code walkthrough: Contract Test demonstrating Specmatic JMS mock in action

+ + +

We have a service layer which fetches data from a domain service or an HTTP dependency and then sends messages to a JMS queue.

-
+ + + +
+ + + + + +

The specmatic.json file of this application provides an AsyncAPI specification for the application’s JMS dependency, an OpenAPI specification for the application’s HTTP dependency for the domain service, and also an OpenAPI specification for the application itself, which Specmatic will use to run contract tests.

-
+ + + +
+ + + + + +

Since we are talking about JMS, let’s have a look at the AsyncAPI specification. We have defined a queue named product queries, and this is the schema of the messages that it is expected to receive. For the contract tests, we first set the host and the port which Specmatic will use to run contract tests against the application.

-
+ + + +
+ + + + + +

Then we specify an endpoints API which Specmatic will use to determine the routes exposed by this application. For this, we use the mappings endpoint provided by the Spring Actuator library.

-
+ + + +
+ + + + + +

If we look at the controllers in this application, we can see that there are two routes defined. Specmatic will use this information to generate a coverage summary report, which we shall see shortly.

-
+ + + +
+ + +

+ + +

Back to the contract tests, we next create the JMS mock and set expectations on it. What we are saying here is that we expect that a queue named product-queries will receive three messages on it.

-
+ + + +
+ + + + + +

Next, we create the HTTP stub, set expectations on it, start the application, and run the tests. After all contract tests are executed, we check if the expectations set on the JMS mock are met. To do this, we call the verifyExpectations method. The verify expectations method will assert that the product-queries queue received exactly three messages, and all three messages match the schema defined in the specification. If either of these conditions are not met, the verifyExpectations method will report errors.

-
+ + + +
+ + + + + +

With this background, let’s run the contract tests. We can see all contract tests have passed.

-
+ + + +
+ + + + + +

Now, looking at the Coverage Summary Report we can see again there are two routes defined in the application. But since in the OpenAPI specification of this application, there is only one route defined, we see only one route is reported with state is covered, one while the other one is reported with state is missed.

-
+ + + +
+ + + + + +

Let’s now look at the API tests.

+ + + + + +

Code walkthrough: API Test demonstrating Specmatic JMS mock in action

+ + +

In this class, we have tests to validate each of the routes defined in the application. This is the test in which we expect messages on the JMS mock. So we start by setting expectations on the JMS mock similar to what we saw in the contract test. We expect three messages on the productQueries queue.

-
+ + + +
+ + + + + +

We then set expectations on the HTTP stub. We invoke the API or route. We validate the response, and then we assert if the expectations set on the JMS mock are met by calling the verifyExpectations method similar to the way we did it in the contract test.

-
+ + + +
+ + + + + +

We also further assert the actual message received by JMS mock by calling the object message received on channel method as described here.

-
+ + + +
+ + + + + +

With all this setup, we run the API tests. Here we can see all the API tests have passed as well.

-
+ + + +
+ + + + + +


The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+ + +

Available in the Pro plan or higher

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-jms
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1009,7 +1306,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/kafka-mocking-with-asyncapi-using-specmatic/index.html b/updates/kafka-mocking-with-asyncapi-using-specmatic/index.html index 5f20de2db..f210e2d14 100644 --- a/updates/kafka-mocking-with-asyncapi-using-specmatic/index.html +++ b/updates/kafka-mocking-with-asyncapi-using-specmatic/index.html @@ -3,8 +3,8 @@ - -Kafka Mocking with AsyncAPI using Specmatic - Specmatic + + Kafka Mocking with AsyncAPI using Specmatic - Specmatic @@ -15,6 +15,7 @@ + @@ -55,36 +56,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Kafka Mocking with AsyncAPI using Specmatic

+ + + +
+ + +

Kafka Mocking with AsyncAPI using Specmatic

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Check out the sample code

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-nodejs
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + +

In our previous post, we looked at how we can stub out redis with Specmatic so that we can test our application independent of its dependency on Redis. In this post we will be looking at mocking Kafka with Specmatic by leveraging AsyncAPI specification.

+ + + + + +

Overview – how Specmatic can be used to mock Kafka using AsyncAPI

-
+ + + +
+ + + + + +

Let’s take the example of an HTTP consumer that sends a request to an API application. The request is received by the controller, which invokes a service layer that fetches data from an HTTP API dependency, and then drops a message onto a Kafka topic. The service layer returns a response to the controller, which in turn returns a response to the consumer.

+ + +

To test this application independently, we need to isolate it from its http and Kafka dependencies. Specmatic can stub Http API dependencies by leveraging their OpenAPI specifications. For asynchronous interactions such as those over Kafka, Specmatic can leverage AsyncAPI specifications.

+ + +

To isolate our application / system under test from its Kafka dependency, let us take an  AsyncAPI specification that defines the format for messages on the Kafka topic and mock it out using Specmatic’s Kafka mock.

+ + +
Overview – how Specmatic can be used to mock Kafk type: string YAML
+ + + + + +

Let’s say we also use Specmatic to run contract tests against the application. First, we must set expectations on  the Kafka mock about messages that it will receive. Then we must set expectations (response mappings) on Specmatic HTTP stub that is leveraging the OpenAPI specification of the HTTP dependency (Domain Service in the diagram above). You can learn more about contract testing and HTTP stubbing with Specmatic in other videos. Finally, Specmatic uses the application’s OpenAPI specification to run contract tests against it.

+ + +

Each contract test sends a request to the application which is received by the controller which in turn invokes the service layer. The service layer fetches data from the HTTP service stub and drops a message onto the topic on the Kafka mock. The Kafka mock uses an in memory Kafka broker, so the service layer sends messages to it seamlessly. Because of this, to the application it will be exactly like sending messages to a real Kafka broker in production. The service layer responds to the controller, which in turn responds to the contract test. After the contract tests have run, Specmatic asks the Kafka mock to verify the messages that it received. Let’s see this in an actual example.

+ + + + + +

Code walkthrough: Contract Test demonstrating Specmatic Kafka mock in action

+ + +

Here’s an application that fetches data from an HTTP API and writes a message to a Kafka broker.

-
+ + + +
+ + + + + +

Here is a specmatic.json, in which we provide the path to AsyncAPI specification file for mocking out the Kafka dependency, the OpenAPI specification for stubbing out the HTTP dependency which the application needs, and the OpenAPI specification of the application itself which Specmatic will use to run contract tests.

-
+ + + +
+ + + + + +

Now, let’s run the contract tests.

-
+ + + +
+ + + + + +

In the API coverage summary for the above test, we have a contract test for one of the APIs, but not for the other, and so it’s marked as missed.

+ + +

Let’s look at how the Kafka expectations are being set and verified.

-
+ + + +
+ + + + + +

After starting the Specmatic Kafka mock, we set an expectation that it would receive a single message on the “product queries” topic. When the test runs, any messages received on this topic are validated against the product queries schema in the AsyncAPI specification. Finally, we verify the kafka mock. This checks if, as per expectations, the mock has received a single message at the product queries topic, and if that message adhered to the AsyncAPI specification. If either of these conditions are not met, or say if a topic that has not been captured in the AsyncAPI specification received a message, the verification fails. The message verification process lets the test keep a tight rein on all Kafka messages sent by the application.

+ + +

Code walkthrough: API Test demonstrating Specmatic Kafka mock in action

+ + +

The setup for API tests is on similar lines to the Specmatic contract tests. Let’s take a quick look at the test set up.

-
+ + + +
+ + + + + +

Like with the contract tests, we start a Kafka mock, and then we set an expectation that a single message is expected on the product queries topic. Then in the test, we verify that the required message has indeed been received, and this line will verify that only one message on the product queries topic has been received as defined by the expectation set earlier on.

+ + +

Since the Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+ + +

Sample project: https://github.com/znsio/specmatic-order-bff-nodejs
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -1094,7 +1319,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/media/index.html b/updates/media/index.html index 37fbc7862..cd13453c9 100644 --- a/updates/media/index.html +++ b/updates/media/index.html @@ -3,8 +3,8 @@ - -In the Media – Specmatic + + In the Media – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

In the Media

-
-
+
+ + +
+

In the Media

+ +
+
-
-
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
-

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service […]

-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

-
-
+
+
+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+
+
+

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service […]

+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

+
+ +
+
-
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -882,7 +971,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/openapi-example-simplified-visualize-and-generate-domain-specific-test-data/index.html b/updates/openapi-example-simplified-visualize-and-generate-domain-specific-test-data/index.html index f93981d9b..875fd0a41 100644 --- a/updates/openapi-example-simplified-visualize-and-generate-domain-specific-test-data/index.html +++ b/updates/openapi-example-simplified-visualize-and-generate-domain-specific-test-data/index.html @@ -3,8 +3,8 @@ - -OpenAPI Example Simplified: Visualize and Generate Domain-Specific Test Data​ + + OpenAPI Example Simplified: Visualize and Generate Domain-Specific Test Data​ @@ -15,6 +15,7 @@ + @@ -54,36 +55,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

+ + + +
+ + +

OpenAPI Examples Simplified: Visualize and Generate Domain-Specific Test Data​

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Streamlining API Development: An Interactive Guide to Example Generation and Validation using Specmatic 

+ + +

A robust, streamlined approach to API development is crucial for maintaining efficiency, reliability, and scalability in your development pipeline. One powerful methodology that has emerged is Contract-Driven Development (CDD), allowing developers to fully realize the benefits of microservices architectures. This article demonstrates how interactive example generation, validation, and service virtualization can be leveraged seamlessly using API specifications with Specmatic. 

+ + +

The Foundation: API Specifications and Service Virtualization 

+ + +

Let’s say we have an OpenAPI specification encompassing several operations such as finding available products, creating and retrieving orders, and more. This set of operations doesn’t include inline examples, critical for generating meaningful stub data for testing purposes. Specmatic’s interactive example generation makes the process simple and highly efficient. 

+ + +

Interactive Example Generation: Bridging the Gaps 

+ + +

When faced with an API specification devoid of inline examples, the first step is generating these examples. Specmatic includes an interactive examples generator with a user-friendly UI. This interface reflects the operations defined in the API specification, providing a clear visualization for developers. The absence of examples is quickly remedied by Specmatic’s ability to generate them interactively, adhering strictly to the specification’s parameters. 

+ + +

Editing and Validating Generated Examples 

+ + +

In a typical scenario developers might need to tweak the automatically generated examples to fit specific testing contexts. This process is straightforward within Specmatic’s framework. Crucially, modifications are validated and if an example fails to comply with the API’s constraints it is flagged as non-compliant. Immediate feedback on such issues is invaluable, ensuring that deviations from the specification are caught early in the development cycle. 

+ + +

Starting the Stub Server: Bringing Examples to Life 

+ + +

Post-validation, it is simple to launch a stub server using Specmatic. With the enriched examples saved under the _examples directory, the stub server activates, ready to handle requests. Using Postman, we can confirm that the server responds with the exact values previously set, verifying that the stub data accurately reflects the specified operations. This process significantly enhances developers’ ability to mock services, test integrations, and simulate real-world usage without relying on actual service endpoints. 

+ + +

Injecting Domain Context with Dictionary JSON 

+ + +

A critical element in generating meaningful stub responses is the utilization of a dictionary.json file. This file provides domain-specific clues, enabling Specmatic to populate response fields with relevant data, surpassing the generic placeholders often seen in auto-generated examples. This layer of contextual understanding ensures that stub data and test scenarios are not only valid but also relevant and aligned with business logic. 

+ + +

Repurposing Examples for Testing 

+ + +

In a powerful demonstration of Specmatic’s versatility, it can use examples for stub data as well as leveraging them for test data. By simply modifying a command to specify ‘test’ instead of ‘stub’, Specmatic can run comprehensive tests against a live application. This capability is pivotal in validating whether the application responses conform to the API specification and the generated examples. 

+ + +

Upon executing the test, we can see multiple test outcomes, including failures. Through Specmatic’s interactive UI, these failures can be meticulously analyzed, offering deep insights into the root causes. This ensures that any divergence from expected behavior is promptly addressed. 

+ + +

Conclusion: The Power of Executable API Contracts 

+ + +

We have showcased the value of interactive, example-driven API development and the transformative impact of utilizing robust specifications throughout the lifecycle of microservices.  

+ + +

Specmatic exemplifies how API specifications can be used as executable contracts, streamlining the entire development and testing lifecycle. Maintaining the specification in a central Git repository ensures consistency and collaboration among team members, whether they are API providers or consumers. This approach not only reinforces contract-driven development but also fortifies the reliability and predictability of microservices-based architectures. 

+ + +

By embracing tools like Specmatic, developers can enhance their workflows, reduce errors, and ensure the resilience of their APIs from the ground up.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -967,7 +1132,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/openapis-broken-tooling-roundtrip-fidelity-failure-with-codegen-and-docgen/index.html b/updates/openapis-broken-tooling-roundtrip-fidelity-failure-with-codegen-and-docgen/index.html index b332e6857..da6ad711a 100644 --- a/updates/openapis-broken-tooling-roundtrip-fidelity-failure-with-codegen-and-docgen/index.html +++ b/updates/openapis-broken-tooling-roundtrip-fidelity-failure-with-codegen-and-docgen/index.html @@ -3,8 +3,8 @@ - -OpenAPI's Broken Tooling: Roundtrip Fidelity Failure with CodeGen & DocGen​ + + OpenAPI's Broken Tooling: Roundtrip Fidelity Failure with CodeGen & DocGen​ @@ -15,6 +15,7 @@ + @@ -52,36 +53,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

+ + + +
+ + +

OpenAPI’s Broken Tooling: Roundtrip Fidelity Failure with CodeGen and DocGen​

-
-
+Demonstration, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Exploring the Strengths and Weaknesses of Automated API Development 

+ + +

Maintaining well-documented and reliable APIs is essential for any microservices development pipelines. At the heart of this process for OpenAPI specs are two important tools: CodeGen and DocGen. CodeGen, short for code generation, and DocGen, documentation generation, are designed to streamline the development cycle by automating the creation of server code and API documentation from OpenAPI specifications. 

+ + +

The concept is elegant in its simplicity. Start with a clear API specification, use CodeGen to automatically generate the necessary boilerplate code for your API server, and then utilize DocGen to maintain up-to-date documentation. This supposedly creates a seamless, round-trip cycle where the specification and the implementation remain perpetually in sync. 

+ + +

However, the practical application of these tools is not without its pitfalls. When we tested this, comparing the original API specification with the one regenerated from the code, discrepancies like dropped examples and duplicated details came to light. These inconsistencies are more than minor inconveniences; they highlight significant concerns regarding the reliability of these automated tools. 

+ + +

What is Contract-Driven Development? 

+ + +

Contract-Driven Development (CDD) is an approach where API specifications serve as executable contracts between API providers and consumers. This methodology enables efficient communication among teams, ensuring everyone adheres to the agreed-upon API structures. By maintaining these API specifications in a central Git repository, CDD allows for seamless version control and collaboration. 

+ + +

The Round Trip: Specification to Code and Back 

+ + +

Let’s explore an example by introducing a simple OpenAPI specification for a product API. This API includes a single path called /product, which supports the POST method to create a product. The path includes response codes for successful creation (201) and bad requests (400). 

+ + +

To showcase the capabilities of CodeGen, we run a command using the OpenAPI generator, which takes the given specification file and generates boilerplate code for a Spring Boot application. Within moments, the tool produces the necessary controller and other classes. The generated code is substantial enough to bootstrap development and ensure that all components are in place. 

+ + +

Ensuring the Generated Code Works 

+ + +

Next, we employ Maven to compile and run the generated Spring Boot application. This step is crucial to confirm the application’s functionality and ensure it runs without issues. Once the application is up and running, we shift our focus towards using the DocGen tool. 

+ + +

From Code Back to Specification with DocGen 

+ + +

Transitioning to DocGen, we extract the OpenAPI specification from the running code. This round-trip exercise aims to validate the fidelity of the code-to-specification conversion. Ideally, the regenerated specification should match the original specification, thus proving the accuracy and reliability of both CodeGen and DocGen processes. 

+ + +

Identifying Discrepancies and Areas for Improvement 

+ + +

A critical analysis reveals notable discrepancies between the original and the regenerated specification. While comparing the two files, we can see that certain examples in the request and response have been omitted. Furthermore, a significant issue arises with the duplication of fields. In the original schema, the product is composed of product details and an ID using the allOf construct. However, the regenerated specification flattened this structure, leading to unnecessary duplication of data fields. 

+ + +

Limitations and Trust Issues with CodeGen and DocGen 

+ + +

The discrepancies identified during this round-trip test raise significant concerns about the reliability of CodeGen and DocGen, such fundamental mismatches erode trust in these automation tools. When a simple round trip fails to preserve the original schema’s integrity, developers may face challenges in relying on these tools for more complex API specifications. 

+ + +

Conclusion: The Need for Robust Contract-Driven Development Tools 

+ + +

While tools like CodeGen and DocGen offer promising automation capabilities for API development and documentation, this demonstration highlights critical areas where improvements are needed. Contract-Driven Development hinges on the accuracy and reliability of these tools to ensure seamless collaboration and communication among teams. As the industry continues to evolve, robust and trustworthy automation tools will be crucial for maximizing the benefits of microservices architecture. 

+ + +

Next time you consider using CodeGen and DocGen, reflect on this case study and scrutinize whether these tools meet your standards for reliability and accuracy. Investing in comprehensive testing and validation of your API specifications can help mitigate risks and enhance the efficacy of your development processes. 

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -966,7 +1134,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/pacts-dependency-drag-why-consumer-driven-contracts-dont-support-parallel-development/index.html b/updates/pacts-dependency-drag-why-consumer-driven-contracts-dont-support-parallel-development/index.html index 895abeef8..5e2c075d9 100644 --- a/updates/pacts-dependency-drag-why-consumer-driven-contracts-dont-support-parallel-development/index.html +++ b/updates/pacts-dependency-drag-why-consumer-driven-contracts-dont-support-parallel-development/index.html @@ -3,8 +3,8 @@ - -Pact's Dependency Drag​: Why Consumer-Driven Contracts Don't Support Parallel Development + + Pact's Dependency Drag​: Why Consumer-Driven Contracts Don't Support Parallel Development @@ -15,6 +15,7 @@ + @@ -52,36 +53,34 @@ - + - + - - + + - + - + - - - + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

+ + + +
+ + +

Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

-
-
+Demonstration, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment. 

+ + +

In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven contract testing framework—have gained popularity. However, this approach comes with its own set of challenges. This post investigates these challenges and explores the drawbacks of using Pact for contract testing. 

+ + +

The Code-First Approach – Understanding Pact’s Framework 

+ + +

Pact operates on a code-first approach. This means that the developers need to write the unit tests and code for API consumer classes first. Only then can the interactions be mocked using Pact’s Domain Specific Language (DSL). For instance, consider developing an Android application that interacts with a backend for front-end (BFF) service. The developer must first write the Android-specific API client class and its corresponding unit tests. The next step is to use Pact DSL to mock the API provider, aka the backend application. 

+ + +

The Learning Curve 

+ + +

The first significant hurdle faced by developers is the learning curve associated with Pact’s DSL. Not only do developers need to be adept at writing the application code, but they also must familiarize themselves with the intricacies of Pact DSL. This additional layer of complexity can slow down development, especially for teams new to contract testing tools. 

+ + +

Managing the Pact Broker 

+ + +

Centralized Management 

+ + +

Once the interactions between the consumer and mocked providers are established, Pact generates a contract in the form of a JSON file. This file needs to be stored and managed in a central repository known as the Pact Broker. The Pact Broker orchestrates all the generated contract files, making them available for running contract tests against providers. 

+ + +

Maintenance Concerns 

+ + +

The central challenge with the Pact Broker is its maintenance. As an independent server, it needs constant upkeep to ensure it is operational. If the broker goes down, it can disrupt continuous integration (CI) pipelines and block crucial features from being deployed, presenting a significant risk to project timelines and stability. 

+ + +

The Multiplier Effect with Multiple Consumers 

+ + +

Diverse Consumer Expectations 

+ + +

In a real-world scenario, a single API provider often serves multiple consumers. Each consumer, be it iOS, Android, or web applications, will generate its version of the Pact JSON, reflecting what the consumer expects from the provider. The ultimate contract for the BFF is thus an aggregate of all these consumer expectations, making the orchestration far more complex. 

+ + +

Layered Complexity 

+ + +

The backend for front-end application might depend on various other services, leading to intricate dependency chains. In such layered architectures, every service interaction has to be mocked and tested with Pact. The backend calls to domain services necessitate domain API mocks, which generate their contract JSON files. This cumulative build-up of Pact files from multiple services and consumers becomes overwhelmingly intricate. 

+ + +

The Third-Party Dilemma – External Dependencies 

+ + +

The complexity magnifies when services depend on external third-party APIs. These third-party services are beyond the control of the internal development teams. Convincing an external provider to adopt and test against Pact contracts is often impractical, if not impossible. This limits the efficacy of consumer-driven contracts when integrating with third parties. 

+ + +

Duplication of Information – Dual Maintenance 

+ + +

A significant operational challenge is the dual maintenance of OpenAPI specifications and Pact JSON files. OpenAPI is a widely accepted standard that many teams and third-party providers already use for API documentation and development. Introducing Pact JSON as an additional artifact results in duplicated information and fragmented sources of truth. This duplication can cause inconsistencies and outdated contracts, which can lead to integration issues. 

+ + +

Conclusion 

+ + +

Given the steep learning curve, operational complexities, maintenance overheads, and the necessity of managing multiple sources of truth, Pact presents several challenges for contract testing in microservices environments. While it offers a structured way to define and test consumer-provider interactions, its constraints make it less suitable for many real-world scenarios. This underscores the importance of weighing these challenges against the benefits before adopting a tool like Pact. Understanding these nuances can help teams make informed decisions that align with their operational dynamics and technical needs. 

+ + +

Specmatic was developed to overcome these shortcomings and to empower developers with the tools to leverage Contract Driven Development and enable the efficient, accelerated and reliable parallel development of microservices. 

+ + +

+ + +

See also: Comparison: Specmatic vs Pact.io and Pactflow.io

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -975,7 +1156,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/page/2/index.html b/updates/page/2/index.html index 8493b3272..d71fac671 100644 --- a/updates/page/2/index.html +++ b/updates/page/2/index.html @@ -3,8 +3,8 @@ - -Updates – Page 2 – Specmatic + + Updates – Page 2 – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - - + + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Updates

-
-
+
+ + +
+

Updates

+ +
+
-
-
-
-

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner

-
-
-
-

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner Read More »

-
-
+
+
+
+

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner

+
+
+
+

Empowering Frontend Engineers with Microservices Contract Testing – a conversation with Markus Oberlehner Read More »

+
+ +
+
-
+
-
-
-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

-
-
-

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

-
-

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

-
-
+
+
+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts

+
+
+

Shift-Left the identification of integration issues in applications built with Event Driven Architecture (EDA) by leveraging AsyncAPI specs as Executable Contracts Introduction The surge in popularity of microservices has revolutionized the way we think about software architecture. However, as systems grow and inter-service communication increases, the risk of integration issues can also rise. One such

+
+

Contract Testing Google Pub/Sub: Using AsyncAPI specs as Executable Contracts Read More »

+
+ +
+
-
+
-
-
-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

-
-
-

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

-
-

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

-
-
+
+
+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest

+
+
+

Testing APIs: Specmatic vs TextTest Emily Bache wanted to compare TextTest with Specmatic and has published a video about her experience: The BEST way to find BUGS in an API | Contract vs Approval Testing She observes, “Specmatic works best when the spec is defined independently in an ongoing discussion about expectations between the service

+
+

Contract vs. Approval Testing: Identifying Bugs in RESTfulBooker’s API with Specmatic and TextTest Read More »

+
+ +
+
-
+
-
-
-
-

Specmatic Docker Image now available

-
-
-

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

-
-

Specmatic Docker Image now available Read More »

-
-
+
+
+
+

Specmatic Docker Image now available

+
+
+

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier. Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic Getting started in 5

+
+

Specmatic Docker Image now available Read More »

+
+ +
+
-
+
-
-
-
-

2023 year in review

-
-
-

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come! In this issue:

-
-

2023 year in review Read More »

-
-
+
+
+
+

2023 year in review

+
+
+

The end of the year is nearly upon us and we have lots to celebrate! Specmatic just turned 4 and the release of version 1.0 of Specmatic this month, was an exciting milestone to achieve. We have rolled out many compelling new capabilities this year and there is much more to come! In this issue:

+
+

2023 year in review Read More »

+
+ +
+
-
+
-
-
-
-

Introduction to Contract Driven Development with Specmatic

-
-
-

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

-
-

Introduction to Contract Driven Development with Specmatic Read More »

-
-
+
+
+
+

Introduction to Contract Driven Development with Specmatic

+
+
+

Transcript Hi, welcome to this demo of contract-driven development where I’m going to use Specmatic, an open-source tool to turn your API specification into executable contracts. We have an app which sends a request to a BFF, a backend for frontend, which in turn sends a request to a domain service. Notice you could have

+
+

Introduction to Contract Driven Development with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Contract Testing with Specmatic - Markus Oberlehner
-

Stubbing an HTTP end-point with Specmatic

-
-
-

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

-
-

Stubbing an HTTP end-point with Specmatic Read More »

-
-
+
+
+
Contract Testing with Specmatic - Markus Oberlehner
+

Stubbing an HTTP end-point with Specmatic

+
+
+

Markus Oberlehner gives a brief overview on the topic of Contract Testing with Specmatic and his experience using it for stubbing an HTTP end-point.

+
+

Stubbing an HTTP end-point with Specmatic Read More »

+
+ +
+
-
+
-
-
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
-

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
-

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

-
-
+
+
+
+

TMForum ODA CTK API specification conformance testing with Specmatic

+
+
+

We recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

+
+

TMForum ODA CTK API specification conformance testing with Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic API Coverage Report
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

-
-
-

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

-
-

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

-
-
+
+
+
Specmatic API Coverage Report
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report

+
+
+

Specmatic’s API coverage report helps identify any mismatches between an OpenAPI specification and an application’s endpoints early in the development lifecycle. The report lists all the endpoints, their coverage, and indicates if they are missing in the spec or not implemented in the application. You can define success criteria for the API coverage report and fix issues.

+
+

Early detection of mismatches between your API specs and implementation: Exploring Specmatic’s API Coverage Report Read More »

+
+ +
+
-
+
-
-
-
JDBC stubbing with Redis and Specmatic contract testing.
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

-
-
-

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

-
-

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

-
-
+
+
+
JDBC stubbing with Redis and Specmatic contract testing.
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing

+
+
+

With Specmatic JDBC stub, you can easily test APIs without the need for a complex database setup. By switching out the real database with a Specmatic JDBC stub, we can set expectations for the stub to respond to specific queries. These expectations can be recorded based on actual interactions. Once the expectations are set, we no longer need the database for our tests!

+
+

Break the Chains of Database Dependencies: Leveraging Specmatic for JDBC Stubbing Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -1039,7 +1148,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/page/3/index.html b/updates/page/3/index.html index 3909ec704..3b51b9b0a 100644 --- a/updates/page/3/index.html +++ b/updates/page/3/index.html @@ -3,8 +3,8 @@ - -Updates – Page 3 – Specmatic + + Updates – Page 3 – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - - + + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Updates

-
-
+
+ + +
+

Updates

+ +
+
-
-
-
-

JMS Mocking with AsyncAPI using Specmatic

-
-
-

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

-
-

JMS Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
+

JMS Mocking with AsyncAPI using Specmatic

+
+
+

The JMS mock is wire compatible and can be controlled entirely from within the test. This means you can run the test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.

+
+

JMS Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Specmatic + Kafka demo video thumbnail
-

Kafka Mocking with AsyncAPI using Specmatic

-
-
-

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

-
-

Kafka Mocking with AsyncAPI using Specmatic Read More »

-
-
+
+
+
Specmatic + Kafka demo video thumbnail
+

Kafka Mocking with AsyncAPI using Specmatic

+
+
+

The Specmatic Kafka mock is wire compatible and entirely within the control of the test, the test can run locally and in CI and deliver quick feedback early in the cycle. So the application itself runs exactly as it would with a real Kafka.

+
+

Kafka Mocking with AsyncAPI using Specmatic Read More »

+
+ +
+
-
+
-
-
-
Redis stubing - specmatic contact development with contract testing.
-

Redis Stubbing with Specmatic Contract Testing

-
-
-

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

-
-

Redis Stubbing with Specmatic Contract Testing Read More »

-
-
+
+
+
Redis stubing - specmatic contact development with contract testing.
+

Redis Stubbing with Specmatic Contract Testing

+
+
+

Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub.

+
+

Redis Stubbing with Specmatic Contract Testing Read More »

+
+ +
+
-
+
-
-
-
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
-

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

-
-
+
+
+
Dave Farley pointing to the Specmatic tool for easy microservice testing, featured on Dave Farley's Continuous Delivery channel.
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+
+
+

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+
+

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel Read More »

+
+ +
+
-
+
-
-
-
Comparison of Specmatic and Spring Cloud Contract.
-

Comparison: Specmatic vs Spring Cloud Contract

-
-
-

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

-
-

Comparison: Specmatic vs Spring Cloud Contract Read More »

-
-
+
+
+
Comparison of Specmatic and Spring Cloud Contract.
+

Comparison: Specmatic vs Spring Cloud Contract

+
+
+

With Spring Cloud Contract we can start by authoring the API contract in one of the supported DSLs, based on which the provider / producer is verified and in the process stubs are generated for consumers. This makes it possible to leverage it as both a “consumer driven” or “provider driven” contract testing tool. There are also some interesting points about how we share contracts and stubs (through artifact managers, source control, etc.) with Spring Cloud Contract. Let us look at the detailed comparison between Specmatic and Spring Cloud Contract. Please do leave a comment if there are other areas of comparison on which you would like to see additional details.

+
+

Comparison: Specmatic vs Spring Cloud Contract Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Wiremock comparison
-

Comparison: Specmatic vs WireMock

-
-
-

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

-
-

Comparison: Specmatic vs WireMock Read More »

-
-
+
+
+
Specmatic vs Wiremock comparison
+

Comparison: Specmatic vs WireMock

+
+
+

API mocking is only effective if the mocks are truly representative of the provider / services they are emulating. Deviations between mocks and providers can lead to integration issues much later in the development cycle. In order to avoid such issues it is important to keep in mind that selecting an API mocking tool is not an isolated decision. It has to be in line with your overall microservices development, testing and deployment goals.

+
+

Comparison: Specmatic vs WireMock Read More »

+
+ +
+
-
+
-
-
-
Specmatic vs Pact & Pactflow comparison
-

Comparison: Specmatic vs Pact.io and Pactflow.io

-
-
-

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

-
-

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

-
-
+
+
+
Specmatic vs Pact & Pactflow comparison
+

Comparison: Specmatic vs Pact.io and Pactflow.io

+
+
+

Specmatic and Contract Driven Development differ significantly from Pact. We built Specmatic out of our own necessity where Pact did not fit the bill for us. We have tried to cover as many areas of comparison as possible, however we would love to hear if you have any other criteria on which you would like to see additional details.

+
+

Comparison: Specmatic vs Pact.io and Pactflow.io Read More »

+
+ +
+
-
-
-
-
+ +
+ -
+
-
- + + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+
+ + + - - - + @@ -979,7 +1079,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/redis-stubbing-with-specmatic-contract-testing/index.html b/updates/redis-stubbing-with-specmatic-contract-testing/index.html index b3b545c8c..ac15edfed 100644 --- a/updates/redis-stubbing-with-specmatic-contract-testing/index.html +++ b/updates/redis-stubbing-with-specmatic-contract-testing/index.html @@ -3,8 +3,8 @@ - -Redis Stubbing with Specmatic Contract Testing - Specmatic + + Redis Stubbing with Specmatic Contract Testing - Specmatic @@ -15,6 +15,7 @@ + @@ -55,36 +56,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

Redis Stubbing with Specmatic Contract Testing

+ + + +
+ + +

Redis Stubbing with Specmatic Contract Testing

-
-
+Demonstration, Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Check out the sample code

+ + +

Sample files: https://github.com/znsio/specmatic-redis-sample
Download Specmatic: https://github.com/znsio/specmatic/releases

+ + +

Available in the Pro plan or higher

+ + + + + +

Transcript

+ + +

Overview – how Specmatic can be used to stub out Redis

+ + +

A typical HTTP consumer would send an HTTP request to an API where it is received by a controller. Let’s say the controller needs to fetch some data using a service object, and let’s say the service object looks up the data in an instance of Redis. Redis responds with the data, the service object returns it to the controller, and the controller uses the data to formulate a response to the consumer. This is how it works in production. But in test mode, things might be a little different. Let’s say there’s an OpenAPI specification for the API, and we feed it to Specmatic to run contract tests against the API. Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub. The Redis stub responds and the service class understands it. None the wiser that it isn’t an actual instance of Redis.

+ + +

The stub is wire compatible, so no changes are needed in the service class for this to work.

-
+ + + +
+ + + + + +

Specmatic Redis stub in action

+ + +

Let’s take a sample API that needs Redis to function. Here’s the StoreController class using the StoreService object to look up some data.

-
+ + + +
+ + + + + +

The StoreService object, in turn, looks up Redis. We’re now going to run contract tests against this API using its API specification. The contract tests will be generated from the specification by Specmatic. The specification from which the contract tests are generated is in a central Git repository.

+ + +

You can learn more about how Specmatic runs contract tests in a previous video.

+ + +

Now, let’s run the contract tests. It won’t take long. Let’s take a look at the first test. Let’s scroll down a little in the logs. We can see a test here for a GET API to fetch the description of a store with ID 1. We get this response.

-
+ + + +
+ + + + + +

This description was provided by a Redis lookup. If we scroll up a little, we can see the log from the Redis tab showing the request that it received and the response that it returned. The stub itself is wire compatible. So the same code that talks to an actual Redis instance will talk to Specmatic’s Redis stub. But how did the stub know to return this response? Let’s dig a little deeper. Just after starting up the stubbed Redis instance, we set expectations on it.

-
+ + + +
+ + + + + +

For example, when it receives a GET operation with description hyphen 1, it should return this response, and so on. In fact, we can do dependency fault injection here. The Redis stub can simulate Redis errors to test that our application responds appropriately. The Redis stub setup is self contained within the test. The stub itself starts up within a millisecond. And this is all great because this test can easily run now in CI or even just locally on the laptop.

+ + +

+ + +

Available in the Pro plan or higher

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -966,7 +1149,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/specmatic-2-0-is-out-now-supports-graphql-and-grpc/index.html b/updates/specmatic-2-0-is-out-now-supports-graphql-and-grpc/index.html index b0b6b6df6..6aa37676d 100644 --- a/updates/specmatic-2-0-is-out-now-supports-graphql-and-grpc/index.html +++ b/updates/specmatic-2-0-is-out-now-supports-graphql-and-grpc/index.html @@ -3,8 +3,8 @@ - -Specmatic 2.0 is out! Now supports GraphQL and gRPC - Specmatic + + Specmatic 2.0 is out! Now supports GraphQL and gRPC - Specmatic @@ -15,6 +15,7 @@ + @@ -52,36 +53,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-
- + + + +
+ + +
+

Specmatic 2.0 is out! Now supports GraphQL and gRPC

-
-
+Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +

We’re thrilled to announce the release of Specmatic 2.0.x, a significant milestone release that is set to transform the way developers approach contract testing, intelligent service virtualization and backward compatibility testing. Now you can also transform your GraphQL and gRPC API specs into executable contracts in seconds. Specmatic 2.0 ushers in a new era of API resilience testing. 

+ + +

These enhancements broaden the scope of Specmatic, allowing teams to adopt cutting-edge technologies while ensuring the integrity and reliability of their APIs. It means your team can spend more time building great features and less time worrying about integration hell. This new release 2.0.x stays true to the spirit of Shift Left by adding more to the arsenal of features that enable teams in catching issues early in the development process with the ability to run tests locally and in CI. 

+ + + + + + + + +

What’s new? 

+ + +

GraphQL and gRPC support 

+ + +

Now you can easily set up leverage your GraphQL and gRPC APIs for contract testing, intelligent service virtualisation and backward compatibility testing, just like you would for your OpenAPI-based services. No more complex and brittle setups that involve an assortment of tools – Specmatic handles it all for you, thereby making for a one stop solution that enables a seamless DevEx. 

+ + +

YAML config files 

+ + +

YAML config support has been added in addition to JSON, enabling consistency with the OpenAPI specification format and making for a more concise configuration.    

+ + + + + +
See Specmatic 2.0 in action with GraphQL
+ + + + + +

What’s changing? 

+ + +

Terminology alignment 

+ + +

In a move to improve semantics and better align with Contract Driven Development terminology, the new provides and consumes sections have replaced the test and stub sections. This change reflects Specmatic’s commitment to clarity and usability in API contract testing.  

-
+ + + +
+ + +

Although the test and stub keys will continue to be supported, users are encouraged to adopt the new keys for clarity and consistency. Here’s the documentation. 

+ + +

Introducing a new domain and new group ID 

+ + +

We have a new domain for our website – specmatic.io.  

+ + +

Specmatic packages are now available under a new groupId ‘io.specmatic’.  https://mvnrepository.com/artifact/io.specmatic 
 
Users using Specmatic in projects with JVM languages like Kotlin, Java can migrate to Specmatic 2.0.0 by simply updating their contract tests to import the classes from ‘io.specmatic’ instead of ‘in.specmatic’.   

+ + +

For example, if you had import statements like this: 

+ + +
import net.specmatic.test.whatever; 
+ + +

You’ll now need to update them to: 

+ + +
import io.specmatic.test.whatever; 
+ + +

Pricing update 

+ + +

To leverage these exciting new features and expanded capabilities you will need a paid Specmatic Pro or Enterprise plan. See the updated pricing page for more details 

+ + +

How to get started 

+ + +

For GraphQL and gRPC, the setup process is just as straightforward as it is for OpenAPI. All you need are your GraphQL schema files or gRPC proto files, along with a simple Specmatic configuration, and you’re good to go. 

+ + +

To make it easier for developers to get started with Specmatic 2.0, updated sample projects are readily available. These projects are designed to showcase the full potential of Specmatic’s new features and provide a straightforward path for developers to try out the tool. 

+ + +

Sample gRPC projects 

+ + +

https://github.com/znsio/specmatic-order-bff-grpc-kotlin 
https://github.com/znsio/specmatic-order-api-grpc-kotlin 
https://github.com/znsio/specmatic-order-bff-grpc-go 

+ + +

Sample GraphQL projects: 

+ + +

https://github.com/znsio/specmatic-order-bff-graphql-java 
https://github.com/znsio/specmatic-order-graphql-ui-react 
https://github.com/znsio/specmatic-order-graphql-consumer-java 

+ + +

At its core, Specmatic 2.0 is about empowering developers and teams to build more reliable, efficient, and scalable microservices.  

+ + +

Give it a try and experience the difference for yourself! 

+ + + + + +

+ + +

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -992,7 +1208,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/specmatic-challenge-winners-announced/index.html b/updates/specmatic-challenge-winners-announced/index.html index 265b816a7..80e585550 100644 --- a/updates/specmatic-challenge-winners-announced/index.html +++ b/updates/specmatic-challenge-winners-announced/index.html @@ -3,8 +3,8 @@ - -Specmatic Challenge - winners announced! - Specmatic + + Specmatic Challenge - winners announced! - Specmatic @@ -15,6 +15,7 @@ + @@ -51,36 +52,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-
- + + + +
+ + +
+

Specmatic Challenge – winners announced!

-
-
+Updates / By + +
+ + +
+ + + +
+ + +

The Specmatic challenge is over and we are pleased to announce the winners!

+ + +

Congratulations to Mohd Zaid and Himanshu Singal for successfully completing the challenge and taking home the prizes!

+ + +

You too can experience the power of Contract Driven Development with Specmatic and transform your API specs into executable contracts in seconds. Why not give it a try today?

+ + +

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -940,7 +1054,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/specmatic-docker-image/index.html b/updates/specmatic-docker-image/index.html index d42b9cf43..5d72dbfe4 100644 --- a/updates/specmatic-docker-image/index.html +++ b/updates/specmatic-docker-image/index.html @@ -3,8 +3,8 @@ - -Specmatic Docker Image now available - Specmatic + + Specmatic Docker Image now available - Specmatic @@ -15,6 +15,7 @@ + @@ -53,36 +54,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-
- + + + +
+ + +
+

Specmatic Docker Image now available

-
-
+Feature Spotlight, Updates / By + +
+ + +
+ + + +
+ + +

Specmatic is now available as a Docker image! Turn your API specifications into executable contracts in seconds. Your favorite features such as contract tests, intelligent service virtualization, backward compatibility testing and more are all available through Specmatic Docker image. Getting started has never been easier.

+ + +

Get the Docker Image Now: https://hub.docker.com/r/znsio/specmatic

+ + +

Getting started in 5 min: https://specmatic.in/getting_started.html

+ + +

Here is an example of how you can use the Docker image to run backward compatibility tests in your Gitlab CI pipeline.

+ + +

https://gitlab.com/znsio/contract-driven-development/central-contract-repository/-/blob/main/.gitlab-ci.yml?ref_type=heads

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -943,7 +1060,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/specmatic-featured-on-dave-farleys-continuous-delivery-channel/index.html b/updates/specmatic-featured-on-dave-farleys-continuous-delivery-channel/index.html index 5b09daefc..2c252497e 100644 --- a/updates/specmatic-featured-on-dave-farleys-continuous-delivery-channel/index.html +++ b/updates/specmatic-featured-on-dave-farleys-continuous-delivery-channel/index.html @@ -3,8 +3,8 @@ - -"Easy Microservice Testing" - Specmatic featured on Continuous Delivery channel - Specmatic + + "Easy Microservice Testing" - Specmatic featured on Continuous Delivery channel - Specmatic @@ -15,6 +15,7 @@ + @@ -55,36 +56,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

+ + + +
+ + +

“Easy Microservice Testing” – Specmatic featured on Continuous Delivery channel

-
-
+In the Media, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Why Contract Testing is important for microservices

+ + +

Dave Farley is a respected author and widely recognised proponent of Continuous Delivery. In this video on his Continuous Delivery YouTube channel he discusses why Contract Testing is important for microservices.

+ + +

Contract Tests are important because microservices architecture involves breaking down a system into independently deployable units of software developed by different teams. Each microservice has its own responsibilities and may communicate with other microservices to fulfill a larger system’s functionality.

+ + +

In such a distributed system, it becomes crucial to ensure that the different microservices are compatible with each other and work together seamlessly. By using Contract Testing, teams can define and specify the contracts or interfaces between microservices. These contracts outline how the microservices should interact, including the data formats, communication protocols, and expected behaviors.

+ + +

Contract Testing allows each microservice team to test their changes independently, based on the defined contracts, without the need for extensive integration testing involving all microservices. This decoupling of teams and testing efforts helps to speed up development and allows teams to work more independently.

+ + +

Additionally, Contract Testing helps ensure backward compatibility when making changes to microservices. It allows teams to validate their changes against previous versions of the contracts to ensure that they are not breaking the contracts and causing compatibility issues with other microservices.

+ + +

In summary, Contract Testing is important for microservices because it enables teams to independently test their changes, ensures compatibility between microservices, and helps maintain backward compatibility when making changes to the system.

+ + +

+ + +

Dave Farley identifies the following benefits of using Specmatic for Contract Testing:

+ + +
  1. Contract Testing: Specmatic helps address the challenge of evaluating and ensuring the compatibility and correctness of independently deployable units of software (microservices) developed by different teams. It allows teams to determine the releasability of their changes independently without testing them with everyone else’s changes before release.
  2. + + +
  3. Central Contract Repository: Specmatic enables the storage of contracts, which define the interactions between producers and consumers of services, in a central repository. This allows for easy comparison between different versions of contracts to determine their compatibility and prevent merging of broken or non-backwards compatible contracts.
  4. + + +
  5. Zero-Code Approach: Specmatic offers a zero-code approach to contract testing for many use cases. By specifying contracts in a supported Interface Description Language (IDL) such as OpenAPI, Specmatic can automatically check compatibility, generate contract tests, and generate contract testing stubs that simulate an implementation of the contract for testing purposes.
  6. + + +
  7. Decoupling of Teams: With Specmatic, teams can work independently and prioritize their work according to their own requirements. Each team can make progress without being tightly coupled to other teams, reducing dependencies and increasing the speed of development.
  8. + + +
  9. Automation: Specmatic allows for automation of contract testing and adherence to contracts. Since contracts are clearly defined and specified in software, validating adherence to those contracts becomes a simpler task that can be automated, improving efficiency and reliability of the testing process.
  10. + + +
  11. Potential for Further Development: Specmatic could potentially open the door for more support in facilitating coordination of work between teams without increasing coupling. For example, managing the parallel use of deprecated APIs could be a potential area of development.
+ + +

Get started with Specmatic. Download it here.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -959,7 +1115,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/stubbing-an-http-end-point-with-specmatic/index.html b/updates/stubbing-an-http-end-point-with-specmatic/index.html index 6267c2cca..382c37e13 100644 --- a/updates/stubbing-an-http-end-point-with-specmatic/index.html +++ b/updates/stubbing-an-http-end-point-with-specmatic/index.html @@ -3,8 +3,8 @@ - -Stubbing an HTTP end-point with Specmatic - Specmatic + + Stubbing an HTTP end-point with Specmatic - Specmatic @@ -15,6 +15,7 @@ + @@ -56,36 +57,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -943,7 +1054,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/tmforum-oda-ctk-api-specification-conformance-testing-with-specmatic/index.html b/updates/tmforum-oda-ctk-api-specification-conformance-testing-with-specmatic/index.html index c859b614b..79893445e 100644 --- a/updates/tmforum-oda-ctk-api-specification-conformance-testing-with-specmatic/index.html +++ b/updates/tmforum-oda-ctk-api-specification-conformance-testing-with-specmatic/index.html @@ -3,8 +3,8 @@ - -TMForum ODA CTK API spec conformance testing with Specmatic + + TMForum ODA CTK API spec conformance testing with Specmatic @@ -15,6 +15,7 @@ + @@ -56,36 +57,34 @@ - + - + - - + + - + - + - - - + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

TMForum ODA CTK API specification conformance testing with Specmatic

+ + + +
+ + +

TMForum ODA CTK API specification conformance testing with Specmatic

-
-
+Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Introduction

+ + +

TMForum is a collaborative platform for service providers, technology suppliers, and other stakeholders in the telco space to share best practices, develop standards, and drive innovation. Their Open API program is a global initiative to enable seamless connectivity, interoperability and portability across complex ecosystem services. And in this context, TMForum provides a Conformance Test Kit (CTK) to self-certify implementation of their Open API specifications. This is a great idea. However we recently discovered some major issues with the TMForum Conformance Test Kit (CTK) v5.0.0 and will demonstrate how using Specmatic can address these problems.

-
+ + + +
+ + + + + +

The Problem with CTK5

+ + +

By running the CTK5 test, we discovered that it is possible for the API implementation to successfully pass the conformance verification and yet to be out of sync with the OpenAPI specification that is on their website. When we investigated further, we realized that the CTK contains a copy of the specification on TMForum’s Open API Table. And the Cypress test suite itself is a repetition of several aspects that are already specified in OpenAPI. With this duplication, comes the possibility of divergence and that is exactly what we see when comparing specifications on TMForum Open API Table (for example, the Party API, TMF 632 v5.0.0, published on 19-Sep-23) with copies of the same that ship with the CTK.

-
+ + + +
+ + + + + +

Furthermore, the request payload that users of the CTK are supposed to modify in accordance with their test data setup, is not validated against the OpenAPI specification that is shipped with the CTK5. This may allow users to inadvertently provide an incorrect (OpenAPI schema invalid) request payload and yet successfully pass the conformance test.

+ + +

CTK5 also does not verify request parameters, error response schema and properties of fields such as optionality, nullability that are defined in the OpenAPI specification in the request.

+ + + + + +

Introducing Specmatic

+ + +

To overcome these challenges, we replaced the Cypress tests with Specmatic contract tests. Specmatic leverages the primary source of truth, the API specification on the TMForum website, to generate tests in a completely no-code manner. By validating payloads against the specification, Specmatic ensures that the application remains in sync with the defined API structure and behavior.

+ + + + + +

Benefits of Specmatic

+ + +

There are several advantages of adopting Specmatic for conformance testing:

+ + +

1. Elimination of Duplicate Specifications: With Specmatic, there is only one source of truth—the API specification on the TMForum website. This eradicates the confusion caused by multiple specifications and ensures consistency throughout the testing process.

+ + +

2. Validated Request Payloads: Specmatic validates payloads against the specification before executing tests, preventing out-of-sync requests. This ensures that the implementation adheres to the defined API structure and accurately handles incoming data.

-
+ + + +
+ + + + + +

3. Comprehensive Verification: Unlike the CTK, Specmatic verifies not only the response schema but also other crucial aspects such as 4xx error responses, optionality, nullability, and more. This comprehensive validation guarantees a higher degree of conformance and increases the reliability of API implementations.

-
+ + + +
+ + + + + +

4. Simplified Architecture: By generating tests based on the OpenAPI specification, Specmatic eliminates the need for duplicating logic already present in the specification. This simplification streamlines the testing process and reduces maintenance efforts.

+ + +

5. End-to-End Testing and Fault Injection: Specmatic goes beyond conformance testing by allowing API dependencies to be stubbed out. This enables full end-to-end testing in isolation and even facilitates fault injection to ensure the application can handle various scenarios, such as timeouts and outages.

+ + + + + +

Demonstration and Comparison

+ + +

By running a side-by-side comparison of the issues identified in CTK 5 and how Specmatic effectively addresses them, we can see how Specmatic’s contract tests detect incompatible changes made to the application, validate request payloads, and comprehensively verify 4xx error responses. Additionally, Specmatic provides an API coverage summary, offering an overview of the percentage of APIs that adhere to the specification.

-
+ + + +
+ + + + + +

Conclusion

+ + +

Specmatic presents a superior alternative to the current Cypress based test setup in CTK for conformance testing. By leveraging the primary API specification as the single source of truth, validating request payloads, and generating tests based on the OpenAPI spec, Specmatic ensures accurate conformance of API implementations. With its simplified architecture, comprehensive verification, and additional testing capabilities, we believe Specmatic can resolve current problems and greatly enhance the abilities of the CTK.

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -974,7 +1176,7 @@

Categories

- - + + \ No newline at end of file diff --git a/updates/wiremocks-dirty-secret-ignoring-api-specs-letting-invalid-examples-slip-through/index.html b/updates/wiremocks-dirty-secret-ignoring-api-specs-letting-invalid-examples-slip-through/index.html index c65dcbfcf..b7334c4dc 100644 --- a/updates/wiremocks-dirty-secret-ignoring-api-specs-letting-invalid-examples-slip-through/index.html +++ b/updates/wiremocks-dirty-secret-ignoring-api-specs-letting-invalid-examples-slip-through/index.html @@ -3,8 +3,8 @@ - -WireMock's Dirty Secret: Ignoring API Specs & Allowing Invalid Examples  + + WireMock's Dirty Secret: Ignoring API Specs & Allowing Invalid Examples  @@ -15,6 +15,7 @@ + @@ -52,36 +53,36 @@ - + - + - - + + - + - + - - - + + + - - - - - + + + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ + +
+ + +
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
+ + +
-
-

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

+ + + +
+ + +

WireMock’s Dirty Secret: Ignoring API Specs & Letting Invalid Examples Slip Through 

-
-
+Demonstration, Updates / By + +
+ + +
+ + + +
+ + +
+ + + + + +

Overcoming the Challenges of Hand-Rolled Mocks with Contract-Driven Development 

+ + +

APIs and microservices have transformed the way software systems are built and maintained. However, developing a system that relies on multiple services—both internal and external—presents unique challenges, especially when some services are not fully available. In this critique of WireMock, we examine the critical importance of service mocking, the drawbacks of traditional hand-rolled mocks, and how adopting contract-driven development with API specifications can mitigate common pitfalls. 

+ + +

The Importance of Service Mocking 

+ + +

One of the crucial aspects of modern software development is overcoming dependencies on external and backend services. Imagine you are building an application with several dependencies that are still under construction or intermittently available. The prevailing practice to navigate this obstacle is to create service mocks. These mocks simulate the behaviors of the actual services, allowing for continuous development and testing. 

+ + +

Quick Setup vs. Long-Term Pitfalls 

+ + +

While it’s relatively quick and easy to create hand-rolled mocks based on agreed request-response patterns with other teams, this method has severe drawbacks. As highlighted in our podcast episode, such mocks can quickly fall out of sync with the actual service as it evolves (e.g., upgrading to a new version). This discrepancy can lead to significant issues during integration testing, sparking rework cycles and delaying deployment. 

+ + +

The Role of API Specifications 

+ + +

To counteract these challenges, basing service mocks on API specifications such as OpenAPI or Swagger can make a substantial difference. These specifications serve as a contract between the service provider and consumer, detailing the expected request and response formats. When used correctly, they facilitate service virtualization based on these well-defined contracts. 

+ + +

Real-World Example 

+ + +

Consider an OpenAPI specification that defines a getProducts operation. This operation returns a list of products, where each product adheres to a specific schema. In our example, we’ve used WireMock to set up a service mock adhering to this specification. However, WireMock has some significant limitations, primarily in the realm of example validation. 

+ + +

The Dirty Secrets of WireMock 

+ + +

WireMock is a popular tool for creating service mocks, but it has its set of pitfalls such as allowing you to set up responses that do not conform to the specified schema without providing any form of validation feedback. 

+ + +

No Feedback on Schema Violations 

+ + +

For example, if the API specification indicates that the price field should be a number (specifically a float), WireMock will still allow you to set this field as a string without any feedback. This can lead to incorrect mock responses, and any API consumer depending on this information will run into errors. Essentially, you are back to square one with a mock that is not representative of the actual service. 

+ + +

Lack of Developer Workflow Guarantees 

+ + +

Another significant issue is that WireMock does not guarantee that the API specification used in its setup is the same one implemented by the API provider. If the provider updates the API specification without informing the consumers, the mock remains outdated. The only point where this mismatch becomes apparent is during integration testing, but by then, the purpose of service mocking has already been defeated. 

+ + +

Embracing Contract-Driven Development 

+ + +

To overcome these limitations, adopting contract-driven development practices can be transformative. By leveraging API specifications as executable contracts and maintaining them in a central Git repository, all teams—both providers and consumers—can ensure they are working with the correct version of the specification. 

+ + +

Benefits of Centralized Specifications 

+ + +

Centralizing the API specification offers multiple benefits: 

+ + +
  1. Consistency: 
+ + +

Ensures all mock services are consistent with the actual API. 

+ + +
  1. Real-time Updates: 
+ + +

Any changes in the API specification are immediately available to all teams. 

+ + +
  1. Validation: 
+ + +

Tools can be put in place to automatically validate that any mock conforms to the latest API specification. And example validation against API specification is crucial such as the capabilities provided by Specmatic Smart Service Virtualization. 

+ + +

Conclusion 

+ + +

As microservices and APIs continue to dominate the software development landscape, the importance of robust, reliable service mocking cannot be overstated. Hand-rolled mocks can provide a quick fix but are fraught with long-term pitfalls. Leveraging API specifications for service virtualization addresses these issues, ensuring consistency and reliability. Tools like WireMock have their uses but fall short in critical areas like example validation and adherence to specifications. By embracing contract-driven development and maintaining centralized API specifications, teams can avoid the pitfalls of traditional mocks and fully realize the benefits of microservices. 

+ + +

Whether you are a seasoned developer or just getting started with microservices, understanding the nuances of service mocking and API specifications can set your project up for success. 

+ + +

+ + +

+ + +

See also: Comparison: Specmatic vs WireMock

+ + + +
+
-
+ + -
+
-
- -
-
- + + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -990,7 +1194,7 @@

Categories

- - + + \ No newline at end of file diff --git a/workshop/feed/index.xml b/workshop/feed/index.xml index e1b2466e0..95772d16d 100644 --- a/workshop/feed/index.xml +++ b/workshop/feed/index.xml @@ -12,7 +12,7 @@ https://specmatic.io/ Contract Driven Development - Wed, 23 Oct 2024 06:19:24 +0000 + Wed, 30 Oct 2024 08:22:49 +0000 en-US hourly diff --git a/workshop/index.html b/workshop/index.html index 98b5d4389..f010b8e1c 100644 --- a/workshop/index.html +++ b/workshop/index.html @@ -3,8 +3,8 @@ - -Workshop – Specmatic + + Workshop – Specmatic @@ -15,6 +15,7 @@ + @@ -34,34 +35,34 @@ - + - + - - + + - + - + - - - + + + - - - + + + - + - - + + - - + + + - - + - + + - + + + + + -
-
+ + + + + +
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+ +
+
+
+
+
+ +
+
+
+
+
+
+
+ +
+
+ -
-
-
-
-
- -
-
-
-
-
-
-
- -
-
-
-
-

Workshop

-
+
+ + +
+

Workshop

+ +
+
-
-

It seems we can’t find what you’re looking for. Perhaps searching can help.

- -
+
+ + +

It seems we can’t find what you’re looking for. Perhaps searching can help.

+ + + +
+
-
-
-
-
+ + + +
+ + + +
+ +
-
-
-
-
-
-
-
-
- -
-
-
-
+ +
+
+
+ + -
- -
-
- +
+
+
+
+ +
+
+
+ + + + - - - + @@ -836,7 +922,7 @@

Categories

- - + + \ No newline at end of file