Come faccio a creare un test di integrazione che testa più microservizi senza fare il mocking?

Question

Come faccio a creare un test di integrazione che testa più microservizi senza fare il mocking?

#1 da (1 voti)

0

Comprendo il concetto di derisione delle risposte API e dei loro usi nei test delle unità, ma nei test funzionali / di integrazione, in realtà non voglio prendere in giro perché ciò sconfigge lo scopo.

Ad esempio, se ho il microservizio A e B. Un utente crea un record con A, e A ha bisogno di inviare alcuni dati a B, e B crea un altro record alla sua fine. B richiede i parametri 1, 2 e 4. Tuttavia, in una simulazione, non c'è nulla che garantisca il contratto del servizio B perché tale chiamata API non viene effettivamente effettuata.

In questo momento ho un contenitore docker per ogni servizio, e sono un po 'perso su come creare questo test.

L'unica cosa che posso pensare è:

Ruota i contenitori richiesti per il test
Crea record con microservice A
Verifica l'esistenza del record in A
Non prendere in giro la chiamata da A a B (in modo che B crei anche il proprio record)
Verifica l'esistenza del record in B
Ruota i contenitori

Qualche idea sul modo migliore per farlo?

unit-testing integration-tests functional-testing test-scenarios

posta john 20.06.2018 - 01:09

fonte

1 risposta

Leggi altre domande sui tag unit-testing integration-tests functional-testing test-scenarios

Rappresentazione di oggetti serializzati in Javascript da PHP for-loops vs x.Times (...) metodi di estensione

score 1 · Answer 1

Non dovresti testare il punto 5 (verificando che B abbia creato un record) in quel test che esiste nel progetto A.

Invece ciò di cui si parla è verificare che A implementa il contratto di B nel modo giusto. Fidati che B funzioni correttamente.

Anche questo è il primo passo per farlo. Ma per essere più completo, vorrei invece testare solo una classe (chiamiamola BImp) facendo chiamate a B in ogni modo possibile. In questo modo crei un record in A e poi asserisci correttamente il tuo BImp implementa B, quindi un altro test non sarebbe quello di creare un record in A e dimostrare che BImp implementa ancora correttamente i ritorni di errore di B in quel contesto.

Dopo che Bimp è stato completamente testato e sotto controllo, è possibile sostituire le chiamate B dirette a livelli più alti con le chiamate BImp e deriderle per provare ogni tracciato. Ciò consente anche una separazione più semplice dei test di integrazione (di BImp) poiché sarà più lento e, naturalmente, non sarà necessario eseguire nuovamente il test di B se è necessario utilizzarlo in un altro segmento del tuo codice.