Kādi ir mikroservisu testēšanas raksturlielumi…

Mikroservisu testēšana koncentrējas uz komponentu un moduļu līmeni, uzsverot atsevišķu pakalpojumu izolāciju un savstarpējo mijiedarbību, atšķirībā no monolītajām programmām, kurās tests aptver visu koda bāzi kā vienu veselumu.

Mikroservisu testēšanas īpatnības:

Pakalpojumu izolācija: Katrs mikroserviss tiek testēts atsevišķi, neatkarīgi no citiem. Tas ļauj ātri identificēt problēmas konkrētajā pakalpojumā.
Līgumu testēšana (Contract Testing): Savstarpējās mijiedarbības pārbaude starp pakalpojumiem, lai pārliecinātos, ka tie pareizi apmainās ar datiem un atbilst iepriekš noteiktiem API līgumiem. Populāri rīki: Pact.
Integrācijas testēšana: Vairāku mikroservisu savstarpējās mijiedarbības pārbaude un ar ārējām atkarībām (datu bāzēm, ziņojumu rindām). Sarežģītība slēpjas daudzās atkarībās.
Testu datu pārvaldība: Nepieciešams ģenerēt un uzturēt testu datus katram pakalpojumam atsevišķi, ņemot vērā to iespējamās atkarības no citiem pakalpojumiem.
Testu koordinācija: Dažādu mikroservisu testu palaišanas koordinēšana, īpaši integrācijas testos.
Kļūdu un elastības testēšana: Pakalpojumu uzvedības pārbaude, ja citi pakalpojumi neizdodas vai ir liela slodze.
Infrastruktūras testēšana: Nepieciešama sarežģītāka testēšanas infrastruktūra mikroservisu izvietošanai un pārvaldībai.
Drošības testēšana: Uzsvars uz autentifikācijas, autorizācijas un citu drošības aspektu pārbaudi katra pakalpojuma līmenī un to savstarpējā mijiedarbībā.

Salīdzinājums ar monolītu:

Aspekts	Monolītā lietojumprogramma	Mikroservisi
Testēšanas apjoms	Visa koda bāzes testēšana kā vienots veselums.	Katras pakalpojumā izolēta testēšana, pēc tam to integrācija.
Atkarības	Iekšējās atkarības vienas koda bāzes ietvaros.	Ārējās tīkla atkarības starp neatkarīgiem pakalpojumiem.
Testu dati	Var būt centralizēti.	Nepieciešama katra pakalpojuma atsevišķa pārvaldība, ņemot vērā atkarības.
Integrācija	Moduļu integrācijas testēšana vienā procesā.	Savstarpējās mijiedarbības testēšana tīklā.
Neatkarība no kļūdām	Mazāk aktuāli moduļu līmenī, vairāk visā lietojumprogrammā.	Kritiski svarīgi testēt uzvedību, ja atsevišķi pakalpojumi neizdodas.
Sarežģītība	Testēšana var būt vienkāršāka infrastruktūras ziņā, bet sarežģītāka izolācijas ziņā.	Testēšana ir sarežģītāka infrastruktūras un atkarību pārvaldības dēļ, bet vienkāršāka pakalpojumu izolācijā.

Piemērs Contract Test ar Pact:

// pact_broker/pacts/consumer-producer/latest.json
{
  "consumer": {
    "name": "MyConsumer"
  },
  "provider": {
    "name": "MyProducer"
  },
  "interactions": [
    {
      "description": "Lietotāja pieprasījums pēc ID",
      "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"
    }
  }
}

Šis JSON pavyzdys apibūdina sutartį tarp vartotojo (MyConsumer) ir tiekėjo (MyProducer), kuris nurodo tikėtiną užklausą ir atsakymą, gaunant naudotoją pagal ID. Vartotojas generuos panašią sutartį savo pusėje, o tiekėjas patikrins, ar jo API atitinka šią sutartį.

Kādi ir mikroservisu testēšanas raksturlielumi komponentu un moduļu līmenī salīdzinājumā ar monolītajām lietojumprogrammām?