Contract testing

Il contract testing (test dei contratti) verifica l’accordo tra due servizi in isolamento. Ogni lato viene testato rispetto a una descrizione condivisa delle interazioni, il contratto, invece che rispetto all’altro servizio in esecuzione. Se il provider cambia il nome di un campo su cui un consumer fa affidamento, un contract test fallisce nella pipeline del provider stesso, prima che venga rilasciato qualsiasi cosa. Per costo e affidabilità si colloca tra i test di integrazione e i test end-to-end.

Come funziona il consumer-driven contract testing

La forma più diffusa, resa popolare dallo strumento Pact, è guidata dal consumer:

1. Il consumer scrive un test contro un provider simulato (mock), dichiarando le richieste che invia e le parti della risposta che usa davvero. Per esempio: GET /orders/42 restituisce 200 con un id numerico e uno status di tipo stringa.
2. L’esecuzione di quel test produce un file di contratto (un “pact”) che registra quelle interazioni.
3. Il contratto viene condiviso, di solito tramite un servizio broker.
4. Il provider verifica il contratto riproducendo ogni richiesta registrata contro la propria implementazione reale e controllando che le risposte corrispondano.
5. Prima del rilascio, un team verifica che la versione che sta per rilasciare sia compatibile con le versioni dell’altro lato già presenti in quell’ambiente.

Poiché il consumer elenca solo i campi che usa, il provider è libero di aggiungere campi o di cambiare tutto ciò da cui nessun consumer dipende.

Differenza rispetto a controlli simili

• La validazione dello schema confronta una risposta con lo schema pubblicato dal provider. Ti dice che il provider è coerente con la propria documentazione, non che soddisfa ancora le esigenze di ciascun consumer.
• I test di integrazione chiamano il provider reale. Richiedono che entrambi i servizi e le loro dipendenze siano in esecuzione, e tendono a essere più lenti e più instabili.
• I test end-to-end dimostrano che un percorso completo funziona, ma sono un modo lento e costoso per scoprire che un campo è stato rinominato.

I contratti guidati dal provider, in cui il provider pubblica una specifica OpenAPI e i consumer si testano rispetto a essa, sono un’alternativa quando il provider non può conoscere né coordinarsi con tutti i suoi consumer, come nel caso di un’API pubblica.

Errori comuni

• Specificare troppo. Fare asserzioni su valori esatti o su ogni campo trasforma i contratti in fragili test funzionali. Usa matcher di tipo e includi solo ciò che il consumer legge.
• Testare la logica di business nei contratti. I contratti verificano la forma della conversazione; la correttezza va testata nei test del provider stesso.
• Trascurare i provider state. “L’ordine 42 esiste” deve essere preparato lato provider durante la verifica, altrimenti la verifica fallisce per il motivo sbagliato.