მიკროწესვებსა და მოდულების დონეზე ტესტირების მახასიათებლები რა არის და როგორ განსხვავდება მონოლითური პროგრამების ტესტირებიდან?

მიკროსერვისების ტესტირება ფოკუსირებულია კომპონენტებისა და მოდულების დონეზე, სადაც ყურადღება გამახვილებულია ცალკეული სერვისების იზოლაციაზე და ურთიერთქმედებაზე, განსხვავებით მონოლითური პროგრამების ტესტირებისგან, სადაც ტესტირება მოიცავს მთელ კოდს ბაზას მთლიანად.

მიკროსერვისების ტესტირების თავისებურებები:

• სერვისების იზოლაცია: თითოეული მიკროსერვისი ტესტირდება ცალკე, დამოუკიდებლად სხვა სერვისებისგან. ეს საშუალებას აძლევს სწრაფად გამოავლინოს პრობლემები კონკრეტულ სერვისში.
• კონტრაქტების ტესტირება (Contract Testing): სერვისებს შორის ურთიერთქმედების შემოწმება, რათა დარწმუნდეთ, რომ ისინი სწორად ცვლიან მონაცემებს და შესაბამისი არიან წინასწარ განსაზღვრულ API კონტრაქტებს. პოპულარული ინსტრუმენტები: Pact.
• ინტეგრაციის ტესტირება: რამდენიმე მიკროსერვისის ურთიერთქმედების შემოწმება ერთმანეთთან და გარე დამოკიდებულებებთან (მონაცემთა ბაზები, შეტყობინებების რიგები). სირთულე მდგომარეობს მრავალი დამოკიდებულების მართვაში.
• ტესტის მონაცემების მართვა: საჭირო არის თითოეული სერვისისთვის დამოუკიდებლად გენერირება და შენახვა, მათ შორის დამოკიდებულებების გათვალისწინებით.
• ტესტების ორგანიზება: სხვადასხვა მიკროსერვისისთვის ტესტების გაშვების კოორდინაცია, განსაკუთრებით ინტეგრაციის ტესტირების დროს.
• შეცდომებისა და ელასტიურობის ტესტირება: სერვისების ქცევის შემოწმება სხვა სერვისების გაუქმების ან მაღალი დატვირთვის დროს.
• ინფრასტრუქტურის ტესტირება: საჭიროებს უფრო რთულ ტესტ ინფრასტრუქტურას, მიკროსერვისების განთავსებისა და მართვისთვის.
• უსაფრთხოების ტესტირება: ფოკუსირება ავტენტიფიკაციის, ავტორიზაციის და სხვა უსაფრთხოების ასპექტების შემოწმებაზე თითოეული სერვისის დონეზე და მათი ურთიერთქმედების დროს.

შედარება მონოლითთან:

ასპექტი	მონოლითური პროგრამა	მიკროსერვისები
ტესტირების მოცულობა	მთელი კოდური ბაზის ტესტირება როგორც ერთ მთლიანობაში.	თითოეული სერვისის იზოლირებული ტესტირება, შემდეგ მათი ინტეგრაცია.
დამოკიდებულებები	შიდა დამოკიდებულებები ერთ კოდურ ბაზაში.	გარე ქსელური დამოკიდებულებები დამოუკიდებელ სერვისებს შორის.
ტესტის მონაცემები	შეიძლება იყოს ცენტრალიზებული.	საჭიროებს მართვას თითოეული სერვისისთვის დამოუკიდებლად, დამოკიდებულებების გათვალისწინებით.
ინტეგრაცია	მოდულების ინტეგრაციის ტესტირება ერთ პროცესში.	სერვისების ურთიერთქმედების ტესტირება ქსელით.
უარყოფითი სიძლიერე	ნაკლებად მნიშვნელოვანია მოდულების დონეზე, უფრო მნიშვნელოვანია მთელი პროგრამის დონეზე.	კრიტიკულად მნიშვნელოვანია ტესტირება სერვისების გაუქმების შემთხვევაში.
სირთულე	ტესტირება შეიძლება იყოს უფრო მარტივი ინფრასტრუქტურის თვალსაზრისით, მაგრამ უფრო რთული იზოლაციის თვალსაზრისით.	ტესტირება უფრო რთულია ინფრასტრუქტურის და დამოკიდებულებების მართვის თვალსაზრისით, მაგრამ უფრო მარტივია სერვისების იზოლაციის მხრივ.

Pact-ის გამოყენებით Contract Test-ის მაგალითი:

// pact_broker/pacts/consumer-producer/latest.json
{
  "consumer": {
    "name": "MyConsumer"
  },
  "provider": {
    "name": "MyProducer"
  },
  "interactions": [
    {
      "description": "მომხმარებლის მოთხოვნა 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"
    }
  }
}

ამ JSON მაგალითი აღწერს კონტრაქტს მომხმარებლის (MyConsumer) და მიმწოდებლის (MyProducer) შორის, რომელიც განსაზღვრავს მოსალოდნელ მოთხოვნას და პასუხს მომხმარებლის ID-ით. მომხმარებელი შექმნის მსგავს კონტრაქტს თავის მხარეს, ხოლო მიმწოდებელი გადაამოწმებს, რომ მისი API შესაბამისია ამ კონტრაქტთან.