Millised on mikroteenuste testimise omadused komponentide ja moodulite tasandil võrreldes monoliitsete rakenduste testimisega?

Mikroteenuste testimine keskendub komponentide ja moodulite tasemele ning rõhutab üksikute teenuste isolatsiooni ja vastastikust suhtlust, erinevalt monoliitsetest rakendustest, kus testimine hõlmab kogu koodibaasi tervikuna.

Mikroteenuste testimise omadused:

• Teenuste isolatsioon: Iga mikroteenus testitakse eraldi, sõltumatult teistest. See võimaldab kiiresti tuvastada probleeme konkreetses teenuses.
• Lepingute testimine (Contract Testing): Teenustevaheline suhtlus kontrollitakse, et veenduda, et nad vahetavad andmeid õigesti ja vastavad eelnevalt määratletud API lepingutele. Populaarsed tööriistad: Pact.
• Integreerimise testimine: Mitme mikroteenuse vaheline suhtlus ja väliste sõltuvuste (andmebaasid, sõnumijärjed) kontrollimine. Komplekssus seisneb sõltuvuste haldamises.
• Testandmete haldamine: Vajalik on iga teenuse jaoks eraldi testandmete genereerimine ja haldamine, arvestades nende võimalikke sõltuvusi teiste teenuste andmetest.
• Testide koordineerimine: Erinevate mikroteenuste testide käivitamise koordineerimine, eriti integratsioonitestide puhul.
• Vigade ja elastsuse testimine: Teenuste käitumise kontrollimine, kui teised teenused ebaõnnestuvad või on suur koormus.
• Infrastruktuuri testimine: Vajalik on keerukam testimisinfrastruktuur mikroteenuste juurutamiseks ja haldamiseks.
• Turvalisuse testimine: Fookus autentimise, autoriseerimise ja teiste turvaaspektide kontrollimisel iga teenuse tasemel ja nende vahelises suhtluses.

Võrdlus monoliidiga:

Aspekt	Monoliitne rakendus	Mikroteenused
Testimise maht	Kogu koodibaasi testimine kui tervik.	Iga teenuse isoleeritud testimine ja nende integratsioon.
Sõltuvused	Sise-sõltuvused ühe koodibaasi sees.	Välised võrgusõltuvused sõltumatute teenuste vahel.
Testandmed	Võivad olla tsentraliseeritud.	Vajab iga teenuse jaoks eraldi haldamist, arvestades sõltuvusi.
Integratsioon	Moodulite integratsiooni testimine ühes protsessis.	Teenustevaheline suhtlus võrgus.
Veadekindlus	Vähem oluline moodulite tasandil, rohkem kogu rakenduse tasandil.	Kritiline testida käitumist, kui üksikute teenuste ebaõnnestumised.
Keerukus	Testimine võib olla infrastruktuuri poolest lihtsam, kuid keerulisem isolatsiooni poolest.	Testimine on keerulisem infrastruktuuri ja sõltuvuste haldamise tõttu, kuid lihtsam teenuste isolatsiooni poolest.

Näide Contract Test Pacti kasutamisel:

// pact_broker/pacts/consumer-producer/latest.json
{
  "consumer": {
    "name": "MyConsumer"
  },
  "provider": {
    "name": "MyProducer"
  },
  "interactions": [
    {
      "description": "Kasutaja päring ID järgi",
      "request": {
        "method": "GET",
        "path": "/users/123",
        "headers": {
          "Accept": "application/json"
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json"
        },
        "body": {
          "id": 123,
          "name": "John Doe"
        }
      }
    }
  ],
  "metadata": {
    "pactRust": {
      "version": "1.0.0"
    },
    "pactSpec": {
      "version": "3.0.0"
    }
  }
}

See JSON näide kirjeldab lepingut kasutaja (MyConsumer) ja teenusepakkuja (MyProducer) vahel, määratledes oodatava päringu ja vastuse kasutaja ID-ga. Kasutaja genereerib sarnase lepingu oma poolel, ning teenusepakkuja kontrollib, kas tema API vastab sellele lepingule.