introduction contract testing with examples
Aquest tutorial sobre proves de contracte del pacte explica què és la prova de contractes basada en el consumidor, com funciona i per què l’haureu d’utilitzar a la vostra estratègia de prova:
Què és la prova contractual?
Les proves de contracte dirigides pel consumidor són una forma de proves de l'API que realment permet desplaçar-se cap a l'esquerra. L’eina contractual que fem servir és Pact.io , i en coneixerem més endavant en aquesta sèrie de tutorials.
La prova de contracte és un mètode per verificar la integració entre dues aplicacions de forma independent per tal de provar el que s'ha aprovat i veure si el que es retorna coincideix amb el 'contracte'.
Les proves contractuals s’adapten molt bé a una arquitectura de microserveis, que funcionen en un entorn àgil. Per tant, els exemples es basaran en l’experiència que hem adquirit treballant en aquest entorn.
Què aprendreu:
- Llista de tutorials d'aquesta sèrie de proves de contracte
- Proves de contractes impulsades pel consumidor
- Contracte de proves contra proves d’integració
- Integració contínua
- Conclusió
Llista de tutorials d'aquesta sèrie de proves de contracte
Tutorial # 1: Introducció a la prova de contractes amb exemples (Aquest tutorial)
Tutorial # 2: Com escriure una prova del pacte del consumidor a JavaScript
Tutorial # 3: Com publicar un contracte de pacte per a un agent de pactes
Tutorial # 4: Verifiqueu el contracte del pacte i el desplegament continu amb el CLI del pacte
Proves de contractes impulsades pel consumidor
El punt de partida és la documentació de l’API que constitueix el contracte per a les proves; en aquest moment, normalment, els equips de desenvolupament prenen el document API i es desenvolupen en funció del document wiki (o del format que resideixi a la vostra organització, com ara Document Word).
Per exemple, una aplicació web on el front-end està sent desenvolupat per Team Krypton i l’API per Team Thoron. El projecte comença amb una reunió inicial on es presenten els requisits i s’acorden entre els equips.
Tots els equips compleixen els requisits i comencen a crear el backlog millorant les històries. El desenvolupament comença en els dos equips seguint les històries dels usuaris, les proves d'integració es deixen per a sprints posteriors. A mesura que Team Krypton troba requisits addicionals, relacionats amb escenaris d'errors, la documentació de l'API s'actualitza en conseqüència.
Team Thoron afegeix casos de prova relacionats amb els escenaris actualitzats en funció de la documentació.
Ja podem veure un parell d’errors amb aquest procés i n’he afegit un parell més per tenir sort:
- És possible que els canvis de documents API no es comuniquin amb eficàcia.
- L’equip front-end elimina el servei back-end i viceversa.
- L’equip de fons crea casos de prova d’integració basats en la documentació.
- L’entorn d’integració és la primera vegada que es prova la integració completa.
- Diferents versions d'API en entorns d'integració i producció.
Les proves de contracte dirigides pel consumidor tenen dues vessants, és a dir, el consumidor i el proveïdor. Aquí és on es dóna la volta al pensament tradicional sobre proves en microserveis.
El Consumidor és el comissari dels escenaris, inclosa la sol·licitud i la resposta esperada. Això us permet seguir Llei del llit el que dicta que ha de ser flexible en allò que pot acceptar la seva API, però conservador en allò que s'envia. Referint-nos de nou als defectes núm. 1, 3 i 4, els canvis de documentació són impulsats pel consumidor.
Per exemple, en el cas que Team Thoron canviï un camp de cadena per no acceptar valors nuls, les proves del consumidor no reflectirien el canvi i, per tant, fracassarien. O almenys fins que s’hagin fet els canvis a l’equip Krypton.
(imatge font )
El Proveïdor verifica els escenaris proporcionats pel consumidor en relació amb el seu entorn “dev”. Això permet aplicar els vostres microserveis Canvi paral·lel que indica que hauríeu d'ampliar la funcionalitat de l'API, seguida de la migració a una nova versió. Referint-se de nou al defecte núm. 2, ara els esquemes creats normalment pels equips de back-end per als seus propis requisits de proves es poden basar en els escenaris de consum Pact Stub Server .
L'element vinculant de les dues parts és el 'contracte' que cal compartir entre els equips. El pacte proporciona una plataforma que permet compartir els contractes anomenats Pact Broker (disponible com a servei gestionat amb Pactflow.io ).
El Corredor emmagatzema la producció dels escenaris de consum. El contracte s’emmagatzema al corredor al costat de la versió de l’API. Això permet fer proves amb diverses versions de l'API, de manera que la compatibilitat es pot confirmar abans de la versió, tal com es posa de manifest al defecte núm. 5.
Un avantatge addicional per al Pact Broker a les plataformes heretades és la visibilitat dels consumidors. Els autors de l'API no han conegut tots els consumidors, sobretot, no és com es consumeix.
Referint-se específicament a una ocurrència en què es donaven suport a dues versions de l'API, hi ha hagut un problema de dades a la versió 1 (V1) pel qual l'API causava dades brutes a la base de dades.
El canvi es va implementar a la V1 de l'API i es va impulsar a la producció, però, el consumidor va confiar en el format que causava l'emissió de dades, trencant així la seva integració amb l'API.
Com funciona
A l'exemple anterior es mostra el flux d'autenticació, el servei web requereix que els usuaris s'autentiquin per accedir a dades confidencials. El servei web envia una sol·licitud a l'API per generar un testimoni mitjançant un nom d'usuari i una contrasenya. L'API retorna un testimoni de portador que s'afegeix a la sol·licitud de dades com a capçalera d'autenticació.
La prova del consumidor construeix una sol·licitud POST per a un testimoni passant el cos amb el nom d'usuari i la contrasenya.
Durant la prova es genera un simulador de servidor que valida la sol·licitud que construïu, juntament amb la resposta esperada que en aquest exemple inclou el valor del testimoni.
La sortida de la prova del consumidor genera un fitxer de contracte de pacte. Això s’emmagatzemarà a l’agent de pactes com a versió 1.
A continuació, el proveïdor treu la versió 1 del gestor de pactes i repeteix aquesta sol·licitud contra el seu entorn local, verificant que la sol·licitud i la resposta coincideixen amb els requisits del consumidor.
Rols i responsabilitats
Garantia de qualitat (QA) / provador: Crear contractes mitjançant Pact.io i treballar amb BA per generar els escenaris de prova.
Desenvolupador: Emparellar-se amb els QA per crear les proves i ajudar a ajustar l'API per implementar-lo en integració contínua (CI).
Analista de negocis (BA): Generar els escenaris i treballar amb l'arquitecte per verificar les parts afectades.
Arquitecte de solucions (Pot no existir a la vostra organització): accionar els canvis de l'API i coordinar-vos amb el BA en la implementació, comunicant també els canvis als consumidors (utilitzant el Pact Broker per entendre a qui pot afectar).
Gestió de llançaments: (Sí, sé que és passat de moda, però encara existeix al meu món): plena de confiança que els canvis es publicaran amb èxit a causa de la cobertura de les proves del contracte.
Tot l'equip: Verifiqueu els resultats per determinar si les versions es poden introduir a la producció amb l'eina Pact CLI, Puc desplegar .
Contracte de proves contra proves d’integració
Les proves d’integració han d’existir per validar si el sistema funciona abans de la promoció a l’entorn de producció, però els escenaris es poden reduir significativament.
L'impacte d'això podria ser:
- Comentaris més ràpids abans de llançar-los a l'entorn d'integració.
- Menys dependència de l'estabilitat de l'entorn d'integració.
- Menys entorns que admeten diverses versions d'API.
- Reducció d’instàncies d’entorn inestable a causa de problemes d’integració.
| Integració | Contracte | |
|---|---|---|
| Fracàs clar | Moltes capes | Molt fàcil |
| Configuració de l'API | Sí | no |
| Comprovacions de desplegament | Sí | no |
| Versió de l'API | Sí | Sí |
| Depurar localment | no | Sí |
| Qüestions ambientals | Sí | no |
| Temps de retroalimentació | Lent | Ràpid |
En primer lloc, les proves de contracte no substitueixen les proves d’integració. Però probablement pot substituir alguns dels vostres escenaris de proves d’integració existents, canviar cap a l’esquerra i proporcionar retroalimentació més ràpida al cicle de vida del desenvolupament de programari.
A les proves d'integració, comprovareu el context en què viu l'API, com ara l'arquitectura de l'entorn, el procés de desplegament, etc.
Per tant, voleu executar els escenaris de prova bàsics que confirmarien la configuració, per exemple, el punt final del control de salut per a la versió de l’API. També es demostra si el desplegament va tenir èxit retornant una resposta de 200.
A la prova de contractes, proveu els detalls específics de l'API, que inclou els casos marginals relacionats amb l'estructura de l'API, el contingut (per exemple, existeixen valors de camp, claus) i respostes d'error. Per exemple, l'API gestiona valors nuls o s'elimina de la resposta de l'API (un altre exemple real).
Alguns avantatges (si encara no heu venut)
A continuació, es detallen alguns dels avantatges que cal aprofitar mentre es venen proves de contractes a l’empresa en general:
- Desplegament més ràpid de programari
- Una única font de veritat
- Visibilitat de tots els consumidors
- Facilitat de proves amb diferents versions de l'API.
Preguntes freqüents
Algunes de les preguntes més freqüents en intentar persuadir la gent perquè adoptin proves de contractes són:
Q # 1) Ja tenim un 100% de cobertura de proves, de manera que no la necessitem.
Resposta: Bé, això és impossible, però les proves contractuals tenen molts altres avantatges que la simple cobertura de proves.
Q # 2) És responsabilitat de Solution Architect comunicar els canvis de l'API.
Resposta: La qualitat és responsabilitat de tot l’equip.
P # 3) Per què estem creant els escenaris de prova per a l'equip API?
Resposta: L’equip de l’API no sap com funciona el servei web, per què hauria de ser responsable.
Q # 4) Les nostres proves d'extrem a extrem cobreixen tot el flux de principi a fi, inclosos altres punts d'integració.
Resposta: Exactament per què dividim les proves per provar una cosa i no és responsabilitat vostra provar el flux d’extrem a extrem d’un sistema que no sabeu com funciona.
P # 5) Al repositori de quin equip viuen les proves?
Resposta: Tots dos. El consumidor al seu dipòsit i el proveïdor al seu. Aleshores, al punt central, el contracte viu fora de cap d’ells.
Arguments
Aquests són els arguments contra els quals ens costa argumentar a l’hora de passar al contracte per provar:
com executar un fitxer torrent
- Ja hi ha documentació Swagger que es pot utilitzar per generar proves d’integració.
- Els equips posseeixen serveis front-end i back-end amb un mecanisme eficaç per als canvis d’API.
Integració contínua
Com s'adapta això al vostre conjunt de proves d'integració contínua? El lloc desitjable per viure les proves contractuals és amb les proves unitàries.
Les proves del consumidor generen un simulador de servidor que no requereix dependències externes fora de la prova.
Les proves del proveïdor requereixen una instància de l'API, per tant l'API local es pot embolicar amb un fitxer servidor de proves a la memòria . Tanmateix, si no és fàcil embolicar la vostra API localment, una solució alternativa que hem utilitzat anteriorment és la de configurar un entorn i desplegar el codi a aquest entorn com a part de les comprovacions automàtiques de sol·licitud d'extracció.
(imatge font )
Conclusió
En aquest tutorial, hem après què significa la prova de contractes i com es veu en una infraestructura de microserveis i hem vist com es veu en un exemple del món real.
S'han après lliçons sobre com les proves de contracte us poden ajudar a desplaçar les proves d'integració cap a l'esquerra. A més, hem vist com pot reduir els costos de la vostra organització reduint els temps de retroalimentació relacionats amb problemes d’integració.
La prova de contractes no només és una eina per a proves tècniques, sinó que fa complir la col·laboració dels equips de desenvolupament mitjançant la comunicació de canvis i el foment de la prova com a una sola unitat. En general, aquest hauria de ser un requisit previ per a qualsevol persona que vulgui passar al desplegament continu.
NEXT Tutorial
Lectura recomanada
- Com escriure una prova del pacte del consumidor a JavaScript
- Verifiqueu el contracte del pacte i el desplegament continu amb el CLI del pacte
- Com publicar un contracte de pacte per a un agent de pactes
- Procés d’integració contínua: Com millorar la qualitat del programari i reduir el risc
- Les diferències entre la prova unitària, la prova d’integració i la prova funcional
- Què és la prova d'integració (Tutorial amb exemple de prova d'integració)
- Top 10 d'eines de proves d'integració per escriure proves d'integració
- Desplegament continu a DevOps