streamalism.org

1. Áttekintés

Ebben a rövid cikkben a fogyasztó által vezérelt szerződések fogalmát fogjuk megvizsgálni.

Az integrációt egy külső REST szolgáltatással teszteljük egy szerződés segítségével, amelyet a Egyezmény könyvtár. Ezt a szerződést az ügyfél meghatározhatja, majd a szolgáltató átveheti és felhasználhatja szolgáltatásainak fejlesztésére.

A szerződés alapján teszteket is létrehozunk mind az ügyfél, mind a szolgáltató alkalmazásai számára.

2. Mi az Egyezmény?

Használata Egyezmény, meghatározhatjuk a fogyasztói elvárásokat egy adott szolgáltatóval szemben (amely lehet HTTP REST szolgáltatás) szerződés formájában (innen a könyvtár neve).

Ezt a szerződést az általunk biztosított DSL használatával fogjuk megkötni Egyezmény. Miután meghatároztuk, tesztelhetjük a fogyasztók és a szolgáltató közötti interakciókat a definiált szolgáltatás alapján, amely a meghatározott szerződés alapján jön létre. Emellett tesztelni fogjuk a szolgáltatást a szerződés alapján egy ál-ügyfél használatával.

3. Maven-függőség

A kezdéshez hozzá kell adnunk a Maven-függőséget paktum-jvm-fogyasztó-junit_2.11 könyvtár:

 au.com.dius pact-jvm-consumer-junit_2.11 3.5.0 teszt 

4. Szerződés meghatározása

Amikor tesztet akarunk létrehozni a Egyezmény, először meg kell határoznunk a @Szabály amelyet a tesztünkben használunk:

@Rule public PactProviderRuleMk2 mockProvider = new PactProviderRuleMk2 ("test_provider", "localhost", 8080, ez);

Átadjuk azt a szolgáltató nevet, gazdagépet és portot, amelyen a szerver gúnya elindul (amely a szerződésből jön létre).

Tegyük fel, hogy a szolgáltatás meghatározta a két kezelhető HTTP metódus szerződését.

Az első módszer egy GET kérés, amely két mezővel tér vissza a JSON-hoz. Ha a kérés sikeres, 200 HTTP-válaszkódot és C-t ad visszaontent-Type fejléc a JSON-hoz.

Határozzuk meg egy ilyen szerződést Egyezmény.

Használnunk kell a @Egyezmény megjegyzés és adja át a fogyasztó nevét, amelyre a szerződést meghatározták. Az annotált módszeren belül meghatározhatjuk GET szerződésünket:

@Pact (consumer = "test_consumer") public RequestResponsePact createPact (PactDslWithProvider builder) {Térképfejlécek = új HashMap (); fejlécek.put ("Tartalom-típus", "alkalmazás / json"); return builder .given ("test GET") .uponReceiving ("GET REQUEST") .path ("/ paktum") .metódus ("GET") .willRespondWith () .status (200) .headers (headers) .body ( "{\" feltétel \ ": igaz, \" név \ ": \" tom \ "}") (...)}

Használni a Egyezmény A DSL-ben meghatározzuk, hogy egy adott GET-kérelemhez 200-as választ szeretnénk visszaadni meghatározott fejlécekkel és törzsekkel.

Szerződésünk második része a POST módszer. Amikor az ügyfél POST kérést küld az elérési útvonalra /egyezmény megfelelő JSON törzszel 201 HTTP válaszkódot ad vissza.

Határozzuk meg az ilyen szerződést Egyezmény:

(...) .given ("teszt POST") .uponReceiving ("POST KÉRÉS"). módszer ("POST"). fejlécek (fejlécek) .body ("{\" név \ ": \" Michael \ "} ") .path (" / paktum ") .willRespondWith () .status (201) .toPact ();

Ne feledje, hogy meg kell hívnunk a toPact () módszer a szerződés végén egy példány visszaadására RequestResponsePact.

4.1. Az egyezmény eredményei

Alapértelmezés szerint a Pact fájlok a cél / paktumok mappába. Ennek az útvonalnak a testreszabásához konfigurálhatjuk a maven-surefire-plugin:

 org.apache.maven.plugins maven-surefire-plugin target / mypacts ... 

A Maven build létrehoz egy nevű fájlt test_consumer-test_provider.json ban,-ben target / mypacts mappa, amely a kérések és válaszok felépítését tartalmazza:

{"szolgáltató": {"név": "teszt_provider"}, "fogyasztó": {"név": "teszt_fogyasztó"}, "interakciók": [{"leírás": "KÉRÉS KÉRÉSE", "kérés": {" method ":" GET "," path ":" / "}," response ": {" status ": 200," headers ": {" Content-Type ":" application / json "}," body ": { "feltétel": igaz, "név": "tom"}}, "szolgáltatóStates": [{"név": "teszt GET"}]}}, {"leírás": "POST KÉRÉS", ...}], "metadata": {"pact-specifikáció": {"version": "3.0.0"}, "pact-jvm": {"version": "3.5.0"}}}

5. Az Ügyfél és a Szolgáltató tesztelése a szerződés használatával

Most, hogy megvan a szerződésünk, felhasználhatunk tesztek létrehozására az ügyfél és a szolgáltató számára egyaránt.

Ezen tesztek mindegyike a szerződésen alapuló hasonmását használja fel, azaz:

• az ügyfél egy álszolgáltatót fog használni
• a szolgáltató egy álügyfelet fog használni

Valójában a teszteket a szerződés ellenében végzik.

5.1. Az ügyfél tesztelése

Miután meghatároztuk a szerződést, tesztelhetjük az interakciókat az adott szerződés alapján létrehozandó szolgáltatással. Készíthetünk normál JUnit tesztet, de emlékeznünk kell a @PactVerification annotáció a teszt elején.

Írjunk egy tesztet a GET kéréshez:

@Test @PactVerification () public void givenGet_whenSendRequest_shouldReturn200WithProperHeaderAndBody () {// when ResponseEntity response = new RestTemplate () .getForEntity (mockProvider.getUrl () + "/ pact", String.class); // majd assertThat (response.getStatusCode (). value ()). isEqualTo (200); assertThat (response.getHeaders (). get ("Content-Type"). tartalmaz ("application / json")). isTrue (); assertThat (response.getBody ()). tartalmazza ("feltétel", "igaz", "név", "tom"); }

A @PactVerification az annotáció gondoskodik a HTTP szolgáltatás elindításáról. A teszt során csak a GET kérést kell küldenünk, és azt kell állítanunk, hogy válaszunk megfelel a szerződésnek.

Adjuk hozzá a tesztet a POST metódushíváshoz is:

HttpHeaders httpHeaders = new HttpHeaders (); httpHeaders.setContentType (MediaType.APPLICATION_JSON); Karakterlánc jsonBody = "{\" név \ ": \" Michael \ "}"; // amikor ResponseEntity postResponse = new RestTemplate () .exchange (mockProvider.getUrl () + "/ create", HttpMethod.POST, new HttpEntity (jsonBody, httpHeaders), String.class); // majd assertThat (postResponse.getStatusCode (). value ()). isEqualTo (201);

Mint láthatjuk, a POST kérés válaszkódja megegyezik 201-vel - pontosan úgy, ahogy azt a Egyezmény szerződés.

Ahogy a @PactVerification () kommentár, a Egyezmény A könyvtár a tesztesetünk előtt elindítja a webkiszolgálót a korábban meghatározott szerződés alapján.

5.2. A Szolgáltató tesztelése

A szerződés-ellenőrzés második lépése egy teszt létrehozása a szolgáltató számára, amely a szerződés alapján ál-klienst használ.

Szolgáltatónk megvalósítását a jelen szerződés fogja vezérelni TDD formában.

Például egy Spring Boot REST API-t fogunk használni.

Először is, a JUnit teszt létrehozásához hozzá kell adnunk a pact-jvm-szolgáltató-junit_2.11 függőséget:

 au.com.dius pact-jvm-szolgáltató-junit_2.11 3.5.0 teszt 

Ez lehetővé teszi számunkra, hogy létrehozzunk egy JUnit tesztet a PactRunner és meghatározza a szolgáltató nevét és a paktum tárgyának helyét:

@RunWith (PactRunner.class) @Provider ("test_provider") @PactFolder ("pacts") nyilvános osztály PactProviderTest {// ...}

Ahhoz, hogy ez a konfiguráció működjön, el kell helyeznünk a test_consumer-test_provider.json fájl a paktumok REST szolgáltatási projekt mappája.

Ezután meghatározzuk a szerződésben szereplő interakciók ellenőrzéséhez használt célpontot, és a tesztek futtatása előtt indítsuk el a Spring Boot alkalmazást:

@TestTarget public final Target target = new HttpTarget ("http", "localhost", 8082, "/ spring-rest"); privát statikus ConfigurableWebApplicationContext alkalmazás; @BeforeClass public static void start () {application = (ConfigurableWebApplicationContext) SpringApplication.run (MainApplication.class); }

Végül a szerződésben megadjuk azokat az állapotokat, amelyeket tesztelni akarunk:

@State ("test GET") public void toGetState () {} @State ("test POST") public void toPostState () {}

Ennek a JUnit osztálynak a futtatása két tesztet hajt végre a két GET és POST kérelemhez. Vessünk egy pillantást a naplóra:

A test_fogyasztó és a test_provider közötti paktum ellenőrzése Adott teszt A GET GET REQUEST válasz egy olyan állapotot ad vissza, amelynek 200 állapotkódja (OK) tartalmaz "Content / Type" fejléceket "application / json" értékkel (OK) megfelelő testtel rendelkezik (OK) paktum ellenőrzése A test_fogyasztó és a teszt_provider között adott teszt A POST POST REQUEST egy olyan választ ad vissza, amelynek állapotkódja 201 (OK) és megfelelő teste van (OK)

Ne feledje, hogy a REST szolgáltatás létrehozásának kódját itt nem szerepeltük. A teljes körű szolgáltatás és teszt a GitHub projektben található.

6. Következtetés

Ebben a gyors bemutatóban áttekintettük a fogyasztók által vezérelt szerződéseket.

Szerződést hoztunk létre a Egyezmény könyvtár. Miután meghatároztuk a szerződést, tesztelhettük az ügyfelet és a szolgáltatást a szerződéssel szemben, és kijelenthettük, hogy megfelelnek a specifikációnak.

Ezeknek a példáknak és kódrészleteknek a megvalósítása megtalálható a GitHub projektben - ez egy Maven projekt, ezért könnyen importálhatónak és futtathatónak kell lennie.