Er skjema-validering nok? Forstå nyansene av Contract Testing

I mine tidligere blogger om kontraktstesting skrev jeg hovedsakelig om skjema-validering. For mange nybegynnende kontraktstestere er denne formen for testing lett å forstå og implementere. Men er det tilstrekkelig å ha bare skjema-validering? Jeg vil gi en kort oversikt over de forskjellige typene av kontraktstesting i denne bloggen.

1. Skjema-Valideringstesting

Definisjon: Sikrer at data utvekslet mellom forbruker og leverandør matcher et forhåndsdefinert skjema, med fokus på datatyper, strukturer og formater.

Eksempel: Se for deg et endepunkt i vårt bokhandel-API, /api/books/{bookId}. Den forventede responsen kan være:

{
    "id": "12345",
    "title": "Journey to Middle-Earth",
    "author": "J.R.R. Token",
    "publishedDate": "1970-01-01",
    "price": 15.99,
    "inStock": true
}

En skjema-valideringstest vil verifisere typer og formater av hvert felt. En returnert price som "15.99" (string) i stedet for 15.99 (float) ville utløst en testfeil.

Fordeler:

• Gir rask strukturell tilbakemelding.
• Sikrer grunnleggende inter-service kommunikasjonsoverhold.

Ulemper:

• Bekrefter ikke datakorrekthet eller rekkevidde.
• Begrenset valideringsdybde.

2. Leverandør Kontraktstesting

Definisjon: Sikrer at leverandøren (f.eks., bokhandel-APIet) opprettholder sin kontrakt, og verifiserer både struktur og data nøyaktighet.

Eksempel: Vårt API lover en 404-status med "Book not found" for ugyldige bookIder. Hvis en ikke-eksisterende bookId returnerer en 200-status med et tomt objekt, indikerer det brudd på leverandørkontrakten.

Fordeler:

• Validerer dataens nøyaktighet.
• Sikrer at leverandører opprettholder deres kontraktsbetingelser.

Ulemper:

• Krever mer vedlikehold.
• Er avhengig av kontraktens nøyaktighet og dybde.

3. Forbruker Kontraktstesting

Definisjon: Sentraliserer forbrukerens forventninger, og sikrer at leverandørens data er handlingsbar for forbrukeren.

Eksempel: En front-end som bruker vårt API forventer inStock-feltet for å vise tilgjengelighet. Hvis APIet utelater dette, mislykkes testen, og bevarer forbrukerens funksjonalitet mot leverandørforandringer.

Fordeler:

• Sikrer at leverandør ivaretar forbrukerbehov.
• Identifiserer potensielt skadelige endringer for forbrukeren.

Ulemper:

• Behov for hyppige oppdateringer for utviklende forbrukerforventninger.
• Kan være utfordrende hvis flere forbrukere har forskjellige leverandørforventninger.

4. Mock-Testing

Definisjon: Bruker mock-respons basert på forhåndsdefinerte forhold for å verifisere hvordan et system reagerer uten å kalle den faktiske tjenesten.

Eksempel: En mock-test for vårt /api/books/{bookId} endepunkt kan bruke et fast svar for å simulere ulike scenarier, som boktilgjengelighet eller utilgjengelighet, uten å koble til den faktiske databasen.

Fordeler:

• Lar deg teste selv når noen tjenester ikke er tilgjengelige.
• Hjelper med å simulere forskjellige forhold, som tjenestefeil.

Ulemper:

• Garanterer ikke at den virkelige tjenesten vil oppføre seg som mocken gjør.
• Risiko for at mocks blir utdaterte, noe som reduserer testpålitelighet.

5. End-to-End (E2E) Testing

Definisjon: Tester systemet som en helhet, og validerer integrerte komponenters kollektive atferd.

Eksempel: En E2E-test kan simulere en bruker som browser vår bokhandel, velger en bok via /api/books/{bookId}, legger den til i handlekurven og fullfører et kjøp, og sørger for at alle integrerte tjenester fungerer sammenhengende.

Fordeler:

• Gir det mest helhetlige synet på systemhelse.
• Bekrefter den samarbeidende atferden til alle integrerte deler.

Ulemper:

• Har en tendens til å være tregere på grunn av sin omfattende natur.
• Kan være mer utfordrende å identifisere spesifikke problemer hvis tester mislykkes.

Konklusjon:

Kontraktstesting er flerdimensjonal. Mens skjema-validering legger grunnlaget, krever effektiv kommunikasjon mellom tjenester en blanding av tester: skjema-validering, leverandør- og forbruker kontraktstester, mock-tester og E2E-tester. Gjennom vår bokhandelsanalogi blir betydningen av hver type tydelig, noe som understreker behovet for en omfattende tilnærming. Slik forståelse utruster team til å konstruere en robust mikrotjenestearkitektur, klargjort for motstandskraft og pålitelighet.