խոսեք միկրոսերվիսի պայմանագրային թեստավորման մասին։

Կոնտակտային թեստավորումը կենտրոնացած է միկրոսերվիսների փոխազդեցության ստուգման վրա նրանց API (կոնտակտ) մակարդակում: Մտադրությունը՝ համոզվել, որ սպառողը (ծառայություն, որը օգտագործում է API-ն) և մատակարարն (ծառայություն, որը տրամադրում է API-ն) պահպանում են որոշակի "կոնտակտ" (հարցման/պատասխանների սխեմա, տվյալների ձևաչափ, սպասումներ):

Հիմնական սկզբունքներ՝

• Սպառող-ուղղորդված: Թեստերը հիմնված են սպառողի սպասումներին: Սպառողը որոշում է, թե ինչ տվյալներ և ձևաչափեր է անհրաժեշտ:
• Երկկողմանի թեստավորում: Ստուգվում է, թե ինչպես է սպառողի կողմը (կարող է աշխատել ներկայիս կոնտակտով), այնպես էլ մատակարարի կողմը (համապատասխան է նրա իրականացմանը սպառողի սպասումներին):
• Արագություն: Թեստերը արագ են կատարվում, հաճախ՝ CI/CD շղթայի շրջանակներում, քանի որ դրանք չեն պահանջում բոլոր կախված ծառայությունների տեղադրում:

Ընթացակարգը սովորաբար ներառում է՝

1. Սպառողը ստեղծում է թեստեր, որոնք նկարագրում են իր սպասումները մատակարարի API-ից: Այս թեստերը ստեղծում են "կոնտակտ":
2. Կոնտակտը հրապարակվում է (օրինակ՝ կենտրոնական պահոցում):
3. Մատակարարը օգտագործում է հրապարակված կոնտակտը իր API-ի իրականացման վավերացման համար: Նա գործարկում է թեստեր (հաճախ՝ մատակարարի կողմից), որոնք ստուգում են, արդյոք նրա API-ն համապատասխանում է կոնտակտին:
4. Եթե սպառողի սպասումներն ու մատակարարի իրականացումը չեն համընկնում, թեստը ձախողվում է՝ նշելով կոնտակտի խախտում:

Գործիքներ՝

• Pact (ամենահաճախ օգտագործվող)
• Spring Cloud Contract
• Swagger/OpenAPI և վավերացման գործիքներ

Առավելություններ՝

• Արագ հայտնաբերում սխալների՝ ինտեգրման ժամանակ՝ խնդիրները հայտնաբերվում են նախքան տեղադրումը:
• Համակցային թեստերի անհրաժեշտության նվազեցում: նվազեցնում է բարդ և դանդաղ ամբողջական թեստերի կախվածությունը:
• Անվտանգ թեստավորում: հնարավորություն է տալիս թեստավորել ծառայությունները անկախ մեկը մյուսից:
• Սպասումների հստակ սահմանում: հստակ սահմանում է կոնտակտը ծառայությունների միջև:

Անբավարարություններ՝

• Չի փոխարինում ամբողջական ինտեգրացիոն թեստերին (միայն ստուգում է API մակարդակով փոխազդեցությունը):
• Պահանջում է կոնտակտների վերսիաների վերահսկում՝ դիսցիպլինա:
• Կարող է ավելի բարդ լինել շատ բարդ կոնտակտներով ծառայությունների համար:

Օրինակ՝ Pact-ի օգտագործմամբ՝

1. Սպառողը (օրինակ՝ Order Service) օգտագործում է Pact գրադարանը՝ ստեղծելու սպառողի կողմի թեստեր:

   // Սպառողի թեստի օրինակ Pact JVM-ով
   @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-ի կանչի տրամաբանություն՝ օգտագործելով mockServer
           // Ստուգում՝ արդյոք սպառողը ճիշտ է մշակել mock-պատասխանը
           HttpResponse response = Request.Get(mockServer.getUrl() + "/products/1").execute().returnResponse();
           assertThat(response.getStatusLine().getStatusCode(), equalTo(200));
       }
   }
   

2. Սպառողի թեստերի իրականացման ժամանակ ստեղծվում է կոնտակտային ֆայլ (.json):
3. Այս ֆայլը հրապարակվում է Pact Broker կամ այլ կենտրոնական պահոց:
4. Մատակարարը օգտագործում է Pact գրադարանը (օրինակ՝ Pact Provider Verifier)՝ իր API-ի իրականացման վավերացման համար՝ ստացված կոնտակտից:

   // Մատակարարի թեստի օրինակ Pact Provider Verifier-ով
   @Provider("ProductService")
   @PactFolder("relative/path/to/pacts") // կամ 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() {
           // Տվյալների նախապատրաստման տրամաբանություն՝ ծառայության համար
       }
   
       // Տեղադրեք ծառայության URL՝ որտեղ աշխատում է թեստավորող ծառայությունը
       @BeforeEach
       void beforeEach(PactVerificationContext context) {
           context.setTarget(new HttpTestTarget("localhost", 8080));
       }
   }
   

5. Մատակարարի կողմից վավերիչը իրական API-ին կանչում է կոնտակտի համաձայն՝ համեմատելով ստացված պատասխանն սպասվածի հետ:

Կոնտակտային թեստավորումը կարևոր է՝ ապահովելու հուսալիություն և սպասվող համակարգերի պահպանելիություն միկրոսերվիսների վրա հիմնված համակարգերում։