Sobes.tech
Middle+

mikroxizmatning shartnoma testlari haqida gapiring.

sobes.tech AI

AIdan javob

Shartnoma asosidagi testlar, mikroxizmatlar o'rtasidagi API (shartnoma) darajasidagi o'zaro ta'sirni tekshirishga qaratilgan. Maqsad — iste'molchi (API-dan foydalanadigan xizmat) va ta'minlovchi (API-ni taqdim etadigan xizmat) muayyan "shartnoma" (so'rovlar/javoblar sxemasi, ma'lumotlar formati, kutishlar) ga rioya qilishlarini ta'minlash.

Asosiy tamoyillar:

  • Iste'molchi-yo'naltirilgan: Testlar iste'molchining kutishlariga asoslangan. Iste'molchi qanday ma'lumotlar va formatlar kerakligini belgilaydi.
  • Ikki tomonlama testlash: Iste'molchi tomonining (hozirgi shartnoma bilan ishlay oladimi) va ta'minlovchi tomonining (uning amalga oshirilishi iste'molchining kutishlariga mos keladimi) tekshirilishini o'z ichiga oladi.
  • Tezlik: Testlar tez bajariladi, ko'pincha CI/CD pipeline doirasida, chunki ular barcha bog'liq xizmatlarni joylashtirishni talab qilmaydi.

Jarayon odatda quyidagilarni o'z ichiga oladi:

  1. Iste'molchi, ta'minlovchi API uchun o'z kutishlarini tavsiflovchi testlarni yaratadi. Bu testlar "shartnoma" ni ishlab chiqaradi.
  2. Shartnoma (masalan, markazlashtirilgan repozitoriyada) e'lon qilinadi.
  3. Ta'minlovchi, API ning amalga oshirilishini tekshirish uchun e'lon qilingan shartnomadan foydalanadi. U odatda ta'minlovchi tomonida testlarni ishga tushiradi, ular API shartnomaga mos kelishini tekshiradi.
  4. Agar iste'molchi kutishlari va ta'minlovchi amalga oshirishlari orasida farq bo'lsa, test muvaffaqiyatsiz bo'ladi va shartnoma buzilganligini ko'rsatadi.

Asboblar:

  • Pact (eng mashhuri)
  • Spring Cloud Contract
  • Swagger/OpenAPI va validatsiya asboblari

Afzalliklari:

  • Integratsiya xatoliklarini erta aniqlash: Muammolar joylashtirishdan oldin aniqlanadi.
  • Integratsiya testlarining ehtiyojini kamaytirish: Murakkab va sekin o'tkaziladigan to'liq testlarga bo'lgan bog'liqlikni kamaytiradi.
  • Mustaqil testlash: Xizmatlarni bir-biridan mustaqil ravishda test qilish imkonini beradi.
  • Kutishlarni aniq belgilash: Xizmatlar o'rtasidagi shartnomani aniq belgilaydi.

Kamchiliklari:

  • To'liq integratsiya testlarini o'rnini bosa olmaydi (faqat API darajasidagi o'zaro ta'sirni tekshiradi).
  • Shartnomalarni versiyalashda intizom talab qiladi.
  • Juda murakkab shartnomalarga ega xizmatlar uchun qiyin bo'lishi mumkin.

Pact bilan foydalanish misoli:

  1. Iste'molchi (masalan, Order Service) Pact kutubxonasidan foydalanib, consumer-side testlarni yaratadi.
    // Pact JVM bilan iste'molchi testining misoli
    @ExtendWith(PactConsumerTestExt.class)
    @PactTestFor(providerName = "ProductService", port = "8080")
    public class ProductServiceContractTest {
    
        @Pact(consumer = "OrderService")
        public RequestResponsePact createPact(PactDslWithRequest r) {
            return r.given("a product with id 1 exists")
                    .uponReceiving("a request for product by id")
                    .path("/products/1")
                    .method("GET")
                    .willRespondWith()
                    .status(200)
                    .headers(Map.of("Content-Type", "application/json"))
                    .body(new PactDslJsonBody()
                            .stringValue("id", "1")
                            .stringValue("name", "Laptop")
                            .numberType("price", 1200.00))
                    .toPact();
        }
    
        @Test
        void testGetProductById(MockServer mockServer) throws IOException {
            // API chaqiruv logikasi
            HttpResponse response = Request.Get(mockServer.getUrl() + "/products/1").execute().returnResponse();
            assertThat(response.getStatusLine().getStatusCode(), equalTo(200));
        }
    }
    
  2. Consumer-side testlar bajarilganda shartnoma fayli (.json) ishlab chiqariladi.
  3. Bu shartnoma fayli Pact Broker yoki boshqa markazlashtirilgan repozitoriyga joylashtiriladi.
  4. Ta'minlovchi (Product Service) Pact Provider Verifier kutubxonasidan foydalanib, shartnoma asosida API ning amalga oshirilishini tekshiradi.
    // Provider testining misoli
    @Provider("ProductService")
    @PactFolder("relative/path/to/pacts") // yoki Pact Broker
    public class ProductServiceVerificationTest {
    
        @TestTemplate
        @ExtendWith(PactVerificationInvocationContextProvider.class)
        public void verifyPact(PactVerificationContext context) {
            context.verifyInteraction();
        }
    
        @State("a product with id 1 exists")
        public void productWithId1Exists() {
            // Ta'minlovchi xizmatida test uchun ma'lumotlar holatini tayyorlash
        }
    
        // Test qilinayotgan xizmatning URL manzili
        @BeforeEach
        void beforeEach(PactVerificationContext context) {
            context.setTarget(new HttpTestTarget("localhost", 8080));
        }
    }
    
  5. Verifier ta'minlovchi tomonida haqiqiy API chaqiradi va javobni shartnoma bilan solishtiradi.

Shartnoma asosidagi testlar, mikroxizmatlar bazasida tizimlarning ishonchliligi va qo'llab-quvvatlanishini ta'minlash uchun muhim amaliyotdir.