Se la suite di test richiede letteralmente ore, è necessario concentrarsi su questo e provare a ottimizzare i test.
Quando si tratta di test in un contesto SOA, è importante essere in grado di:
-
Verifica i componenti interni del servizio prima che lo distribuiscono. I test qui saranno test granulari, in bianco, che verrebbero eseguiti separatamente. Di solito ne avrai molte e ognuna si esibirà in pochi millisecondi. L'intero set dovrebbe richiedere alcuni secondi (in un contesto di un microservizio; per le applicazioni di grandi dimensioni, potrebbero essere alcuni minuti).
-
Verifica le interfacce (include l'interfaccia REST / SOAP fornita da il servizio sotto test, ma anche il modo in cui consuma i servizi sottostanti, non ti piacerà la distribuzione di un servizio che si comporta male nei confronti di altri servizi che usa). Questi test sono leggermente più lenti, ma vengono comunque eseguiti in isolamento. Potrebbero richiedere alcuni minuti.
Una volta superati questi test, è possibile distribuire il servizio in un ambiente di staging che è molto vicino all'ambiente di produzione. Qui è possibile testare più cose:
-
Verifica il servizio in interazione con altri servizi. L'obiettivo di questi test è essere in grado di determinare se le interfacce sono effettivamente compatibili. Non dovrebbe essere necessario dire che affinché questi test abbiano un valore, gli altri servizi devono corrispondere esattamente alle versioni distribuite in produzione. Questi test possono richiedere alcuni minuti.
-
Prova alcuni scenari end-to-end per garantire che l'intera catena funzioni bene. Scegli attentamente gli scenari: dal momento che ogni test può richiedere fino a un minuto, non vuoi troppi test qui. Non è necessario testare tutti i possibili casi, poiché dovresti già avere una copertura sufficiente (e sicurezza) con tutti gli altri test eseguiti in precedenza.
Ora che sei sicuro che il servizio si comporta bene con i servizi distribuiti in produzione, il servizio può essere trasferito su alcune macchine di produzione. Da questo momento:
-
Verifica come il servizio è effettivamente in esecuzione. Mantenerlo in esecuzione per cinque minuti sui server selezionati e verificare se il numero di errori nei registri è aumentato o se gli altri servizi hanno un picco di richieste o altre cose che potrebbero indicare che qualcosa non è corretto. Se ciò accade, il servizio dovrebbe essere ripristinato.
-
Prova alcuni scenari end-to-end che sono i più importanti, per essere sicuri che l'intera catena funzioni anche in produzione. Ad esempio, per un sito di e-commerce, un singolo test che registra un utente, aggiunge un prodotto a un carrello, effettua un acquisto, paga, poi chiede un rimborso è in gran parte sufficiente: non è necessario effettuare un test aggiuntivo per sapere se l'utente può annullare la registrazione o se un utente può confrontare i prodotti, tali scenari sono troppo piccoli e dovrebbero essere già stati testati in precedenza.
Una volta che il sistema è sicuro che il servizio funziona correttamente in produzione, può essere distribuito sulle restanti macchine di produzione.
It's unclear how to run test suites for changes from branches other than master.
Dipende interamente dalla tua strategia di integrazione continua. In molti casi, si eseguono i test unitari sui rami, ma non esiste un'integrazione continua, il che significa che il codice dalle filiali non viene mai inviato all'ambiente di gestione temporanea. Questo, a sua volta, incoraggia il team ad integrarsi spesso, non usando affatto i rami, o unendoli su base regolare (cioè più volte al giorno, o almeno una volta al giorno).
Si noti che la specificità di un ecosistema dei microservizi è che il vostro prodotto non è l'intero insieme di servizi ; il tuo prodotto è il servizio specifico. Ciò significa che quando cambi la sua implementazione, l'unica cosa che ti interessa è che non hai cambiato la sua interfaccia; non appena l'interfaccia non viene modificata, tutti i servizi che utilizzano il servizio che hai modificato dovrebbero funzionare correttamente.
In effetti, non devi neppure sapere quali servizi stanno utilizzando i tuoi.
Allo stesso modo, quando Twilio o Amazon stanno cambiando i loro servizi, non eseguiranno alcun test per garantire che un'applicazione che tu hai scritto che usa i loro servizi funzioni ancora. Allo stesso modo, non testerai la tua app ogni volta che Amazon ridistribuisce S3 (né sapresti che lo hanno ridistribuito).
Questo significa anche che molti dei tuoi sforzi dovrebbero essere spesi nella progettazione accurata delle interfacce:
- Che non avrà bisogno di cambiare continuamente.
- Che sarà dettagliato, non ambiguo e ben documentato.
- Che non perderà l'implementazione.