Stiamo scrivendo un'applicazione cloud in un'architettura di micro-servizi. Abbiamo una buona copertura di test unitari e di integrazione per i singoli servizi e abbiamo una serie di test di accettazione (pubblici) di livello API.
Per semplicità userò un esempio forzato per affrontare il problema in questione. Diciamo che ho una azienda e utente risorse e voglio testare che l'utente A ha accesso a società A la lista degli utenti ma non può elencare gli utenti di Azienda B .
Posso adottare uno dei due approcci di base:
- Supponiamo di avere uno stato nel sistema che è favorevole all'esecuzione di questo particolare scenario
- Bootstrap lo stato utilizzando le API pubbliche.
Non mi piace il primo approccio perché ora devo avere le stesse compagnie di test e gli stessi utenti di test in tutti gli ambienti, avviati in anticipo con qualche script o manualmente. Se i test non riescono a lasciare l'ambiente in uno stato incoerente, la modifica dello stato per assicurarsi di poter testare un nuovo scenario può influire su altri test che non ho toccato. Nella mia esperienza, questi test sono estremamente difficili da mantenere, specialmente quando si cresce o si modifica la funzionalità esistente.
Per i nostri test di accettazione siamo andati con il secondo approccio. Per il mio esempio, creerei due nuove risorse (casuali) dell'azienda, creerei utenti casuali in quelle società e quindi faremo richieste per garantire che gli utenti di una società non possano vedere gli utenti nell'altra. Questa tecnica ha molti vantaggi. Non assume nessuno stato precedente in nessun ambiente, quindi posso eseguirli praticamente ovunque con poco sforzo, i test non si influenzano a vicenda, posso parallelizzare tali test molto facilmente perché corrono sempre nella loro "sandbox". La scrittura di test in questo modo è anche incoraggiata dal libro Consegna continua .
Tuttavia ci siamo imbattuti in un piccolo intoppo. Le nostre API (attualmente) consentire per creare dati nel sistema ma non così tanto pulirlo . Alcuni dati hanno "cancellato" , ma siamo tenuti a conservare alcuni dati e solo "eliminazione morbida" .
Negli ambienti "inferiori" questo non è un grosso problema ma, avvicinandosi all'ambiente di produzione, è più difficile vendere "inquinare" l'ambiente .
Abbiamo bisogno di introdurre API speciali per ripulire i dati (hard delete), ma possono essere utilizzati solo dai test? Devo scrivere una suite di test separata per l'ambiente di produzione che presuppone un determinato stato e forse cambia lo stato delle risorse esistenti ma non aggiunge più dati (livello limitato di test). Eseguo solo test di accettazione durante la finestra di distribuzione e ripristino il database allo stato precedente (potrebbe non funzionare con uno scenario di distribuzione blu / verde)?
Il requisito da parte della direzione è che vogliono test di accettazione da eseguire contro l'ambiente di produzione frequentemente per mostrare che il sistema è ancora in una condizione accettabile in modo che possiamo vedere / risolvere i problemi prima che un utente li veda. Personalmente ritengo che dovrebbe essere sufficiente per eseguire test di accettazione dopo la distribuzione perché le versioni dei servizi e la loro configurazione non cambiano tra le distribuzioni. Gli unici problemi che possono / dovrebbero accadere tra le distribuzioni è che una parte del sistema 'va giù', come l'esaurimento delle connessioni DB, lo spazio su disco che si riempie, ecc ... che dovrebbero essere rilevabili dalla salute 'non funzionale' controllare il tipo di diagnostica Ho sbagliato?