In modernen Microservices-Architekturen sind Anwendungen stark auf die Kommunikation zwischen Diensten angewiesen, häufig über APIs. Es ist von entscheidender Bedeutung, sicherzustellen, dass diese APIs während der Entwicklung und nach Änderungen weiterhin wie erwartet funktionieren. Ein effektiver Weg, dies zu erreichen, ist Consumer Driven Contract Testing (CDCT). CDCT ist eine Methode, die sicherstellt, dass Dienste (Produzenten) die Erwartungen der Dienste einhalten, die ihre APIs nutzen (Konsumenten).
In diesem Leitfaden untersuchen wir, was CDCT ist, wie es funktioniert, welche Bedeutung es für die Gewährleistung zuverlässiger Microservices-Interaktionen hat und wie Sie es mit Tools wie Pact implementieren können.
Was ist verbraucherorientierte Vertragsprüfung?
Consumer-Driven Contract Testing ist eine Teststrategie, die sicherstellt, dass die Kommunikation zwischen Diensten in einer verteilten Architektur den vereinbarten Verträgen entspricht. Es unterscheidet sich von herkömmlichen API-Tests dadurch, dass es sich auf die Bedürfnisse der Verbraucher konzentriert und nicht nur darauf, dass die API selbst korrekt funktioniert. Der Vertrag zwischen dem API-Verbraucher und dem Anbieter wird durch die Erwartungen des Verbrauchers definiert und dieser Vertrag wird anhand der Implementierung des Anbieters überprüft.
Schlüsselbegriffe:
• Verbraucher: Der Dienst, der die API nutzt.
• Anbieter (Produzent): Der Dienst, der die API bereitstellt.
• Vertrag: Eine formelle Vereinbarung zwischen Verbraucher und Anbieter, die das erwartete API-Verhalten festlegt.
Wie funktioniert es?
Bedeutung verbraucherorientierter Vertragstests
In verteilten Architekturen, insbesondere mit Microservices, wird die Verwaltung von Abhängigkeiten zwischen Diensten komplexer. CDCT trägt auf verschiedene Weise dazu bei, diese Komplexität zu lindern:
1. Verhindert Produktionsausfälle
Da Verbraucher selbst definieren, was sie benötigen, werden Änderungen an der API des Anbieters, die nicht den Erwartungen des Verbrauchers entsprechen, frühzeitig in der Entwicklungspipeline erkannt. Dies verringert das Risiko, dass Produktionssysteme aufgrund inkompatibler Änderungen kaputt gehen.
2. Entkopplungsentwicklung
Verbraucherorientierte Vertragstests ermöglichen es Verbrauchern und Anbietern, sich unabhängig voneinander zu entwickeln. Dies ist besonders nützlich, wenn sich Teams oder Dienste separat weiterentwickeln. Verträge dienen als Schnittstelle und stellen sicher, dass die Integration wie erwartet funktioniert, ohne dass in jedem Entwicklungszyklus vollständige Integrationstests erforderlich sind.
3. Schnellere Entwicklungszyklen
Mit CDCT können sowohl Verbraucher als auch Anbieter parallel entwickelt und getestet werden, was die Entwicklung beschleunigt. Anbieter können den Vertrag des Verbrauchers testen, noch bevor der Verbraucher seine Funktionalität vollständig implementiert.
4. Frühzeitige Erkennung von Vertragsverstößen
Änderungen am Anbieter, die gegen den Vertrag verstoßen, werden frühzeitig im Entwicklungsprozess erkannt, sodass Entwickler Probleme beheben können, bevor sie kritisch werden.
So implementieren Sie verbraucherorientierte Vertragstests
Für die Implementierung von CDCT stehen mehrere Tools zur Verfügung, wobei Pact eines der beliebtesten ist. Pact ermöglicht es Verbrauchern, ihre Verträge zu definieren, und Anbietern, diese zu überprüfen.
Hier ist eine Schritt-für-Schritt-Anleitung zur Implementierung von CDCT mit Pact:
Schritt 1: Verbrauchererwartungen definieren
Definieren Sie zunächst im Verbraucherservice den Vertrag. Dazu gehört in der Regel Folgendes:
• Der Endpunkt, den der Verbraucher anruft.
• Die Anforderungsmethode (GET, POST, PUT usw.).
• Der erwartete Anforderungstext oder die erwarteten Parameter.
• Der erwartete Antworttext und Statuscode.
Hier ist ein Beispiel für die Definition eines Vertrags in einem Verbrauchertest mit Pact in JavaScript:
const { Pact } = require('@pact-foundation/pact');
const path = require('path');
const provider = new Pact({
consumer: 'UserService',
provider: 'UserAPI',
port: 1234,
log: path.resolve(process.cwd(), 'logs', 'pact.log'),
dir: path.resolve(process.cwd(), 'pacts'),
});
describe('Pact Consumer Test', () => {
beforeAll(() => provider.setup());
afterAll(() => provider.finalize());
it('should receive user details from the API', async () => {
// Define the expected interaction
await provider.addInteraction({
state: 'user exists',
uponReceiving: 'a request for user details',
withRequest: {
method: 'GET',
path: '/users/1',
headers: {
Accept: 'application/json',
},
},
willRespondWith: {
status: 200,
headers: {
'Content-Type': 'application/json',
},
body: {
id: 1,
name: 'John Doe',
},
},
});
// Make the actual request and test
const response = await getUserDetails(1);
expect(response).toEqual({ id: 1, name: 'John Doe' });
});
});
In diesem Beispiel erwartet der Verbraucher (UserService) vom Anbieter (UserAPI), dass er Benutzerdetails zurückgibt, wenn er eine GET-Anfrage an /users/1 stellt.
Step 2: Publish the Contract
Once the consumer test passes, Pact generates a contract file (Pact file) that can be shared with the provider. This contract can be stored in a Pact broker or a version control system so that the provider can use it for verification.
Step 3: Provider Verifies the Contract
The provider retrieves the contract and verifies that it complies with the consumer’s expectations. This is done by running a Pact test on the provider's side. Here’s an example of verifying a Pact contract in Java:
public class ProviderTest {
@Test
public void testProviderAgainstPact() {
PactVerificationResult result = new PactVerifier()
.verifyProvider("UserAPI", "pacts/UserService-UserAPI.json");
assertThat(result, instanceOf(PactVerificationResult.Ok.class));
}
}
The provider runs this test to ensure that it adheres to the contract specified by the consumer.
Step 4: Continuous Integration
Once CDCT is integrated into your CI/CD pipeline, each time a contract changes, the provider can automatically verify the contract. This ensures that API changes do not break the consumer’s expectations, providing a safety net for both teams.
CDCT Best Practices
When to Use Consumer-Driven Contract Testing
CDCT is particularly useful when:
• You have microservices or distributed architectures with multiple services interacting.
• Teams working on different services need to develop independently without frequent integration testing.
• API contracts are likely to change often, and you want to avoid breaking consumer expectations.
• You need fast feedback loops to detect contract violations early in the development process.
Conclusion
Consumer-driven contract testing offers a reliable way to ensure that services in a distributed system communicate effectively without breaking changes. By focusing on consumer expectations and validating the provider against them, CDCT helps teams develop independently while ensuring stability. Whether you are building microservices, API-based applications, or distributed systems, incorporating CDCT into your testing strategy will improve the reliability and scalability of your services.
Das obige ist der detaillierte Inhalt vonEin Leitfaden für verbraucherorientierte Vertragstests. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
