introduction contract testing with examples
Questo tutorial sul test del contratto patto spiega cos'è il test del contratto basato sul consumatore, come funziona e perché dovresti usarlo nella tua strategia di test:
Che cos'è il test del contratto?
Il test dei contratti orientato al consumatore è una forma di test API che consente davvero il passaggio a sinistra. Lo strumento di contratto che utilizziamo è Pact.io e ne parleremo più avanti in questa serie di tutorial.
Il test del contratto è un metodo per verificare l'integrazione tra due applicazioni in modo indipendente al fine di testare ciò che è stato superato e vedere se ciò che viene restituito corrisponde al 'contratto'.
I test del contratto si adattano perfettamente a un'architettura di microservizi, operando in un ambiente agile. Pertanto gli esempi saranno basati sull'esperienza che abbiamo acquisito lavorando in questo ambiente.
Cosa imparerai:
- Elenco dei tutorial in questa serie di test di contratto
- Test di contratto orientato al consumatore
- Test di contratto vs test di integrazione
- Integrazione continua
- Conclusione
Elenco dei tutorial in questa serie di test di contratto
Tutorial n. 1: Introduzione al test del contratto con esempi (Questo tutorial)
Tutorial n. 2: Come scrivere un test del patto dei consumatori in JavaScript
Tutorial n. 3: Come pubblicare il contratto del patto su Pact Broker
Tutorial n. 4: Verifica il contratto Pact e la distribuzione continua con Pact CLI
Test di contratto orientato al consumatore
Il punto di partenza è la documentazione API che costituisce il contratto per i test, a questo punto di solito i team di sviluppo prendono il documento API e lo sviluppano rispetto al documento wiki (o qualsiasi formato risieda nella tua organizzazione, come il documento Word).
Per esempio, un'applicazione Web in cui il front-end è stato sviluppato dal Team Krypton e l'API è stato sviluppato dal Team Thoron. Il progetto inizia con un incontro iniziale in cui i requisiti vengono presentati e concordati tra i team.
Ogni team prende i requisiti e inizia a creare il backlog perfezionando le storie. Lo sviluppo inizia in entrambi i team seguendo le user story, il test di integrazione viene lasciato per gli sprint successivi. Man mano che il Team Krypton trova requisiti aggiuntivi, in relazione agli scenari di errore la documentazione API viene aggiornata di conseguenza.
I casi di test vengono aggiunti dal Team Thoron relativi agli scenari aggiornati in base alla documentazione.
Possiamo già vedere un paio di difetti con questo processo e ne ho aggiunti altri due per buona fortuna:
- Le modifiche al documento API potrebbero non essere comunicate in modo efficace.
- Il team di front-end interrompe il servizio di back-end e viceversa.
- Il team di back-end crea casi di test di integrazione basati sulla documentazione.
- L'ambiente di integrazione è la prima volta che viene testata la piena integrazione.
- Versione API diversa nell'ambiente di integrazione rispetto alla produzione.
Il test del contratto basato sul consumatore ha due lati, ovvero il consumatore e il fornitore. È qui che viene capovolto il pensiero tradizionale sul test nei microservizi.
Il Consumatore è il curatore degli scenari, compresa la richiesta e la risposta attesa. Questo ti permette di seguire Legge di letto il che ti impone di essere flessibile in ciò che la tua API può accettare ma prudente in ciò che viene inviato. Facendo riferimento ai difetti n. 1, 3 e 4, le modifiche alla documentazione sono guidate dal consumatore.
Per esempio, nella circostanza in cui il Team Thoron modifica un campo stringa per non accettare valori nulli, i test del consumatore non rifletterebbero la modifica e quindi fallirebbero. O almeno fino a quando le modifiche non fossero state apportate al Team Krypton.
(Immagine fonte )
Il Provider verifica gli scenari forniti dal consumatore rispetto al loro ambiente 'dev'. Ciò consente ai tuoi microservizi di applicare Cambio parallelo in cui si afferma che è necessario espandere la funzionalità API, seguita dalla migrazione a una nuova versione. Facendo riferimento al difetto n. 2, gli stub solitamente creati dai team di back-end per i propri requisiti di test possono ora essere basati sugli scenari dei consumatori utilizzando Pact Stub Server .
L'elemento vincolante delle due parti è il 'contratto' che deve essere condiviso tra le squadre. Il patto fornisce una piattaforma per consentire la condivisione dei contratti denominata Pact Broker (disponibile come servizio gestito con Pactflow.io ).
Il Broker memorizza l'output degli scenari di consumo. Il contratto viene quindi archiviato all'interno del broker insieme alla versione dell'API. Ciò consente il test su più versioni dell'API, quindi la compatibilità può essere confermata prima del rilascio, come evidenziato nel difetto n. 5.
Un ulteriore vantaggio del Pact Broker nelle piattaforme legacy è la visibilità dei consumatori. Non tutti i consumatori sono noti agli autori dell'API, soprattutto non è come vengono consumati.
In particolare, facendo riferimento a un evento in cui erano supportate due versioni API, si è verificato un problema di dati all'interno della versione 1 (V1) per cui l'API stava causando dati sporchi nel database.
La modifica è stata implementata nella V1 dell'API e spinta alla produzione, tuttavia, il consumatore ha fatto affidamento sul formato che causava il problema dei dati, interrompendo così la loro integrazione con l'API.
Come funziona
L'esempio sopra mostra il flusso di autenticazione, il servizio web richiede agli utenti di autenticarsi per accedere ai dati sensibili. Il servizio Web invia una richiesta all'API per generare un token utilizzando un nome utente e una password. L'API restituisce un token di trasporto che viene aggiunto alla richiesta di dati come intestazione di autenticazione.
Il test Consumer costruisce una richiesta POST per un token passando il corpo con nome utente e password.
Durante il test viene avviato un server fittizio che convalida la richiesta che costruisci, insieme alla risposta attesa che in questo esempio include il valore per il token.
L'output del test del consumatore genera un file di contratto del patto. Questo verrà archiviato nel broker pact come versione 1.
Il provider quindi estrae la versione 1 dal broker del patto e riproduce questa richiesta nel proprio ambiente locale, verificando che la richiesta e la risposta corrispondano ai requisiti del consumatore.
Ruoli e responsabilità
Controllo qualità (QA) / Tester: Creazione di contratti utilizzando Pact.io e collaborazione con BA per generare gli scenari di test.
Sviluppatore: Accoppiamento con i QA per la creazione dei test e il supporto per il wrapping dell'API per l'implementazione nell'integrazione continua (CI).
qual è il miglior provider di posta elettronica
Analista aziendale (BA): Generazione degli scenari e collaborazione con l'architetto per verificare le parti interessate.
Architetto della soluzione (Potrebbe non esistere nella tua organizzazione): agire sulle modifiche dell'API e coordinarsi con il BA sull'implementazione, comunicando anche le modifiche ai consumatori (utilizzando il Pact Broker per capire chi può interessare).
Gestione del rilascio: (Sì, lo so che è vecchio stile, ma esiste ancora nel mio mondo): Pieno di fiducia che le modifiche verranno rilasciate con successo grazie alla copertura dei test del contratto.
Intera squadra: Verificare i risultati per determinare se le versioni possono essere inviate alla produzione con lo strumento Pact CLI, Posso distribuire .
Test di contratto vs test di integrazione
Devono esistere test di integrazione per convalidare se il sistema funziona prima della promozione nell'ambiente di produzione, ma gli scenari possono essere ridotti in modo significativo.
L'impatto di questo potrebbe essere:
- Feedback più rapido prima del rilascio nell'ambiente di integrazione.
- Meno dipendenza dalla stabilità dell'ambiente di integrazione.
- Meno ambienti che supportano più versioni API.
- Istanze di ambiente instabili ridotte a causa di problemi di integrazione.
| Integrazione | Contrarre | |
|---|---|---|
| Chiaramente individuare il fallimento | Molti strati | Molto facile |
| Configurazione API | sì | Non |
| Controlli di distribuzione | sì | Non |
| Controllo delle versioni delle API | sì | sì |
| Eseguire il debug in locale | Non | sì |
| Problemi ambientali | sì | Non |
| Tempo di feedback | Lento | Veloce |
In primo luogo, il test del contratto non sostituisce il test di integrazione. Ma probabilmente può sostituire alcuni degli scenari di test di integrazione esistenti, spostarsi a sinistra e fornire un feedback più rapido al ciclo di vita dello sviluppo del software.
Nel test di integrazione, verificherai il contesto in cui risiede l'API, come l'architettura dell'ambiente, il processo di distribuzione, ecc.
Pertanto si desidera eseguire gli scenari di test principali che confermerebbero la configurazione, per esempio, l'endpoint del controllo di integrità per la versione api. Dimostrando anche se la distribuzione ha avuto successo restituendo una risposta 200.
Nel test del contratto, stai testando le specifiche dell'API, che include i casi limite relativi alla struttura dell'API, al contenuto (ad esempio, i valori dei campi, le chiavi esistono) e le risposte agli errori. Per esempio, l'API gestisce valori nulli o vengono rimossi dalla risposta API (un altro esempio reale).
Alcuni vantaggi (se non sei già stato venduto)
Di seguito sono elencati alcuni dei vantaggi a cui attingere durante la vendita di test su contratto a un'azienda più ampia:
- Distribuzione più rapida del software
- Un'unica fonte di verità
- Visibilità di tutti i consumatori
- Facilità di test con diverse versioni di API.
Domande frequenti
Alcune domande comuni durante il tentativo di persuadere le persone ad adottare i test del contratto includono:
D # 1) Abbiamo già una copertura del test del 100%, quindi non ne abbiamo bisogno.
Risposta: È impossibile, ma il test del contratto ha molti altri vantaggi oltre alla semplice copertura del test.
D # 2) È responsabilità del Solution Architect comunicare le modifiche all'API.
Risposta: La qualità è responsabilità di tutto il team.
D # 3) Perché stiamo creando gli scenari di test per il team API?
Risposta: Il team API non sa come funziona il servizio web, quindi perché dovrebbe esserci una responsabilità.
D # 4) I nostri test end-to-end coprono l'intero flusso dall'inizio alla fine, inclusi altri punti di integrazione.
Risposta: Esattamente il motivo per cui stiamo dividendo i test per testare una cosa e non è tua responsabilità testare il flusso end-to-end di un sistema di cui non sai come funziona.
D # 5) In quale repository del team risiedono i test?
Risposta: Entrambi. Il consumatore nel loro repository e il provider nel loro. Quindi, nel punto centrale, il contratto vive al di fuori di entrambi.
argomenti
Questi sono gli argomenti contro i quali troviamo difficile argomentare quando si tratta di passare dal contratto al test:
- Documentazione Swagger già in atto che può essere utilizzata per generare test di integrazione.
- I team possiedono servizi sia front-end che back-end con un meccanismo efficace per le modifiche alle API.
Integrazione continua
Come si inserisce questo nella tua suite di test di integrazione continua? Il posto desiderabile per vivere i test a contratto è con i tuoi test unitari.
I test dei consumatori creano un server fittizio che non richiede dipendenze esterne al di fuori del test.
I test del provider richiedono un'istanza API, pertanto è possibile eseguire il wrapping dell'API locale utilizzando un file server di test in memoria . Tuttavia, se non è facile eseguire il wrapping dell'API localmente, una soluzione alternativa che abbiamo utilizzato in precedenza è quella in cui abbiamo creato un ambiente e distribuito il codice in questo ambiente come parte dei controlli automatici della richiesta pull.
(Immagine fonte )
Conclusione
In questo tutorial, abbiamo appreso cosa significa test dei contratti e come appare in un'infrastruttura di microservizi e abbiamo visto come appare in un esempio del mondo reale.
Sono state apprese lezioni su come i test di contratto possono aiutarti a spostare i test di integrazione a sinistra. Inoltre, abbiamo visto come può ridurre i costi per la tua organizzazione riducendo i tempi di feedback relativi ai problemi di integrazione.
Il testing su contratto non è solo uno strumento per i test tecnici, ma impone la collaborazione dei team di sviluppo comunicando i cambiamenti e incoraggiando i test come un'unica unità. Nel complesso, questo dovrebbe essere un prerequisito per chiunque desideri passare alla distribuzione continua.
PROSSIMO Tutorial
Lettura consigliata
- Come scrivere un test del patto dei consumatori in JavaScript
- Verifica il contratto Pact e la distribuzione continua con Pact CLI
- Come pubblicare il contratto del patto su Pact Broker
- Processo di integrazione continua: come migliorare la qualità del software e ridurre i rischi
- Le differenze tra test unitari, test di integrazione e test funzionali
- Che cos'è il test di integrazione (tutorial con esempio di test di integrazione)
- I 10 migliori strumenti di test di integrazione per scrivere test di integrazione
- Distribuzione continua in DevOps