Jakie są cechy testowania mikroserwisów na poziomie…

Testy mikroserwisów na poziomie komponentów i modułów koncentrują się na izolacji i interakcji poszczególnych usług, w przeciwieństwie do testów w monolitycznych aplikacjach, gdzie test obejmuje całą bazę kodu.

Charakterystyka testów mikroserwisów:

Izolacja usług: Testowanie każdego mikroserwisu osobno, niezależnie od innych. Pozwala to na szybkie wykrycie problemów w konkretnym serwisie.
Testy kontraktowe (Contract Testing): Sprawdzanie interakcji między usługami, aby upewnić się, że poprawnie wymieniają dane i spełniają wcześniej zdefiniowane kontrakty API. Popularne narzędzia: Pact.
Testy integracji: Sprawdzanie interakcji wielu mikroserwisów ze sobą i z zewnętrznymi zależnościami (bazy danych, kolejki wiadomości). Złożoność polega na zarządzaniu wieloma zależnościami.
Zarządzanie danymi testowymi: Generowanie i utrzymywanie danych testowych dla każdego serwisu osobno, z uwzględnieniem ich potencjalnych zależności od danych innych serwisów.
Orkiestracja testów: Koordynacja uruchamiania testów dla różnych mikroserwisów, szczególnie w testach integracyjnych.
Testy odporności i elastyczności: Sprawdzanie zachowania serwisów w przypadku awarii innych serwisów lub dużego obciążenia.
Infrastruktura testowa: Wymaga bardziej złożonej infrastruktury do wdrażania i zarządzania wieloma mikroserwisami i ich środowiskami.
Testy bezpieczeństwa: Skupiają się na sprawdzaniu uwierzytelniania, autoryzacji i innych aspektów bezpieczeństwa na poziomie każdego serwisu i podczas ich interakcji.

Porównanie z monolitem:

Aspekt	Aplikacja monolityczna	Mikroserwisy
Zakres testów	Testowanie całej bazy kodu jako całości.	Testowanie każdego serwisu izolowanego, a następnie ich integracji.
Zależności	Wewnętrzne zależności w obrębie jednej bazy kodu.	Zewnętrzne zależności sieciowe między niezależnymi serwisami.
Dane testowe	Mogą być scentralizowane.	Wymagają zarządzania dla każdego serwisu osobno, z uwzględnieniem zależności.
Integracja	Testowanie integracji modułów w obrębie jednego procesu.	Testowanie interakcji serwisów przez sieć.
Odporność	Mniej istotne na poziomie modułów, bardziej na poziomie całej aplikacji.	Krytyczne jest testowanie zachowania w przypadku awarii poszczególnych serwisów.
Złożoność	Testy mogą być prostsze pod względem infrastruktury, ale trudniejsze w izolacji.	Testowanie jest bardziej złożone pod względem infrastruktury i zarządzania zależnościami, ale prostsze w izolacji serwisów.

Przykład testu kontraktowego z Pact:

// pact_broker/pacts/consumer-producer/latest.json
{
  "consumer": {
    "name": "MyConsumer"
  },
  "provider": {
    "name": "MyProducer"
  },
  "interactions": [
    {
      "description": "Żądanie użytkownika po 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"
    }
  }
}

Ten przykładowy JSON opisuje kontrakt między konsumentem (MyConsumer) a dostawcą (MyProducer), określając oczekiwane żądanie i odpowiedź dla pobrania użytkownika po ID. Konsument wygeneruje podobny kontrakt po swojej stronie, a dostawca zweryfikuje, czy jego API jest zgodne z tym kontraktem.

Jakie są cechy testowania mikroserwisów na poziomie komponentów i modułów w porównaniu z testowaniem monolitycznych aplikacji?