adapter-contract-tests

Write shared abstract test suites that verify every adapter behind a port behaves identically.

Updated Jun 25, 2026
One-click install
npx skills add https://github.com/oriddd/ai-toolkit --skill adapter-contract-tests-oriddd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adapter-contract-tests
Source: https://github.com/oriddd/ai-toolkit/tree/main/copilot/public/skills/adapter-contract-tests
Command: npx skills add https://github.com/oriddd/ai-toolkit --skill adapter-contract-tests-oriddd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When multiple adapters (Redis vs Infinispan, Postgres vs Oracle) implement the same port interface, there is no guarantee they behave identically, so swapping providers in production can silently change business behaviour. This Skill solves that by defining one abstract contract test suite (a TCK) per port that every adapter must pass. ## Core Features & Use Cases - Abstract TCK per port: All behavioural assertions live once in an abstract contract class that speaks only the port's language, with no vendor SDK imports. - Thin per-adapter subclasses: Each adapter supplies only an instance, typically backed by Testcontainers for real backends, with in-memory adapters running in Surefire and real I/O adapters in Failsafe. - Composite adapter verification: The composite adapter gets its own contract subclass plus failure-isolation, ordering, and broadcast tests. - Build enforcement: An ArchUnit rule fails the build when any class ending in Adapter lacks a matching ContractTest. - Use Case: You add a new Datadog metrics adapter alongside the existing Prometheus one. Instead of copying tests, you write a five-line subclass of MetricsPortContract and instantly inherit the full behavioural specification. ## Quick Start Ask the AI to apply the adapter-contract-tests skill to generate an abstract contract test for your port interface and a Testcontainers-backed subclass for each adapter implementation.

Frequently Asked Questions about adapter-contract-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test that multiple adapter implementations behave the same?

Write one abstract contract test class per port interface containing all behavioural assertions, then create a thin concrete subclass per adapter that only supplies an instance. Every adapter automatically inherits and must pass the identical assertion set.

What is a TCK in Java testing?

A TCK (Technology Compatibility Kit) is an abstract test class that encodes an interface's behavioural contract as executable assertions. Each implementation subclasses it and provides an instance, proving all implementations are interchangeable.

Can I use Testcontainers with contract tests for Redis or Postgres adapters?

Yes. Real I/O adapter subclasses start a Testcontainers container (for example redis:7-alpine) and wire the adapter to the mapped port. These run in the integration phase via Maven Failsafe, while in-memory adapters run in Surefire.

When is it acceptable to override a contract test in an adapter subclass?

Only when the adapter's documented semantics genuinely differ, such as a NoOp cache where get always returns empty. The override must carry a comment explaining the divergence; all other tests stay inherited.

How do I enforce that every adapter has a contract test in the build?

Add an ArchUnit rule asserting that every class whose name ends in Adapter has a matching ContractTest class. This turns a missing contract into a build failure instead of a silent gap.