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

I den komplekse verdenen av kontraktstesting dukker et aktuelt spørsmål ofte opp: er skjema-validering tilstrekkelig? For å gi klarhet vil vi utforske ulike typer Contract Testing ved å bruke et sammenhengende eksempel på en online bokhandel-API.

Wessel Braakman

Publisert:

17. aug. 2023

Trykk på taggene for å lese mer om hvor og hvordan vi benytter samme fag og teknologi

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.

Artikkel av:

Wessel Braakman
IT-konsulent
Test og Kvalitetssikring