Tecniche di test per applicazioni serverless

Gli approcci principali per eseguire test su codice applicativo serverless sono tre: test con mock, test nel cloud e test di emulazione. In genere è possibile trovare una combinazione di questi approcci in uso nell'ambito di un singolo progetto. Ad esempio, si potrebbe ricorrere al test con mock quando si sviluppa il codice localmente, ma il codice potrebbe essere testato nel cloud come parte di un processo notturno di integrazione continua e distribuzione continua (CI/CD).

Test con mock

Il test con mock è una strategia che consiste nel creare oggetti sostitutivi nel codice che simulino il comportamento dei servizi cloud. Ad esempio, puoi scrivere un test che utilizza un mock del servizio Amazon S3 e puoi configurare quel mock per restituire un oggetto di risposta specifico ogni volta che viene chiamato CreateObjectil metodo. Quando viene eseguito un test, il mock restituisce la risposta senza chiamare Amazon S3 o altri endpoint del servizio.

Questi oggetti sostitutivi vengono spesso generati da un framework fittizio per ridurre la quantità di implementazione necessaria per un determinato test. Alcuni framework fittizi sono generici e altri sono progettati specificamente per. AWS SDKs

I mock, insieme agli stub, rientrano nella categoria più ampia dei fake. I mock differiscono dagli emulatori (discussi più avanti in questa sezione) in quanto i mock vengono in genere creati o configurati da uno sviluppatore come parte del codice di test, mentre gli emulatori sono applicazioni autonome che espongono APIs (come REST APIs) allo stesso modo dei sistemi che emulano.

Di seguito puoi trovare alcuni vantaggi legati all'utilizzo dei mock:

• I simulatori possono simulare servizi di terze parti che sfuggono al controllo dell'applicazione, come APIs i fornitori di software as a service (SaaS), senza bisogno di accedere direttamente a tali servizi.

• I mock sono anche utili per testare le condizioni di errore, soprattutto quando tali condizioni (come nel caso delle interruzioni del servizio) sono difficili da simulare, come un'interruzione del servizio.

• Come gli emulatori, i framework fittizi possono fornire uno sviluppo locale rapido dopo essere stati configurati.

• I mock possono fornire un comportamento sostitutivo praticamente per qualsiasi tipo di oggetto, quindi le strategie di simulazione possono riguardare una più ampia varietà di servizi rispetto agli emulatori.

• Quando diventano disponibili nuove funzionalità o comportamenti, i test simulati possono reagire più rapidamente utilizzando (o ricorrendo a) un framework fittizio generico, in grado di simulare le nuove funzionalità non appena l'SDK aggiornato diventa disponibile. AWS

I test con mock presentano i seguenti svantaggi:

• Generalmente, i mock richiedono un notevole impegno per l'impostazione e la configurazione, in particolare quando si cerca di determinare i valori restituiti da servizi diversi al fine di simulare correttamente le risposte.

• Poiché i mock sono scritti o configurati dagli sviluppatori che scrivono i test, si tratta di una responsabilità aggiuntiva per gli sviluppatori.

• Potrebbe essere necessario accedere al cloud per comprendere APIs e restituire i valori dei servizi.

• I mock possono anche essere difficili da gestire, perché richiedono aggiornamenti ogni volta che le firme delle API cloud simulate cambiano, gli schemi di valori restituiti si evolvono o la logica dell'applicazione testata viene estesa per effettuare chiamate a new. APIs Queste modifiche creano un carico di lavoro aggiuntivo per lo sviluppo dei test per gli sviluppatori.

• I test con mock potrebbero avere un esito positivo negli ambienti desktop ma fallire nel cloud.

• I framework fittizi, come gli emulatori, sono limitati nelle policy di testing or detecting (IAM) o nelle limitazioni delle quote. AWS Identity and Access Management

• Sebbene i mock siano più efficaci per simulare ciò che un'applicazione farà quando l'autorizzazione viene negata o quando viene superata una quota, i test con mock non possono determinare quale risultato si verificherà effettivamente quando il codice verrà implementato nell'ambiente di produzione.

Test nel cloud

I test nel cloud sono il processo di esecuzione di test su codice implementato in un ambiente cloud anziché in un ambiente desktop. Se ci si affida allo sviluppo di applicazioni native del cloud, il valore dei test nel cloud aumenta. Per esempio:

• Puoi eseguire test nel cloud rispetto ai valori più recenti e restituiti. APIs

• I test possono riguardare le policy IAM, le Service Quotas, le configurazioni e tutti i servizi.

• Il tuo ambiente di test cloud è quello che somiglia di più al tuo ambiente di runtime di produzione, quindi è probabile che i test eseguiti nel cloud ottengano risultati più coerenti man mano che avanzano negli ambienti.

I test nel cloud presentano tuttavia alcuni svantaggi. tra cui i seguenti:

• Le implementazioni in ambienti cloud richiedono in genere più tempo rispetto alle implementazioni in ambienti desktop. Strumenti come AWS Serverless Application Model (AWS SAM) Accelerate, AWS Cloud Development Kit (AWS CDK) watch mode e SST aiutano a ridurre la latenza associata alle iterazioni di implementazione del cloud.

• I test nel cloud possono comportare costi di servizio aggiuntivi, a differenza dei test locali, che sfruttano l'ambiente di sviluppo locale.

• Potrebbe essere più difficile eseguire i test nel cloud se non si dispone di un accesso a Internet ad alta velocità.

• I test nel cloud richiedono in genere ambienti cloud isolati l'uno dall'altro. I limiti dell'ambiente vengono spesso tracciati a livello di stack negli account condivisi per gli ambienti di sviluppo, a volte utilizzando strategie di tipo namespace come l'uso di prefissi per identificare la proprietà. Generalmente, per gli ambienti di preproduzione e produzione vengono fissati dei limiti a livello di account per isolare i carichi di lavoro dai problemi di tipo noisy neighbor, per favorire i controlli di sicurezza con privilegi minimi e per proteggere i dati sensibili. La necessità di creare ambienti isolati potrebbe comportare oneri aggiuntivi per i DevOps team, soprattutto se lavorano in un'azienda con controlli rigorosi su account e infrastruttura.

Test di emulazione

I test di emulazione sono abilitati da applicazioni eseguite localmente note come emulatori che assomigliano a servizi. AWS Gli emulatori hanno APIs caratteristiche simili alle loro controparti cloud e forniscono valori di ritorno simili. Possono anche simulare cambiamenti di stato avviati dalle chiamate API. Ad esempio, un emulatore Amazon S3 potrebbe archiviare un oggetto sul disco locale quando viene chiamato il PutObjectmetodo. Quando GetObjectviene chiamato con la stessa chiave, l'emulatore legge lo stesso oggetto dal disco e lo restituisce.

I vantaggi dei test di emulazione sono molteplici:

• Offrono l'ambiente più familiare per gli sviluppatori che sono abituati a sviluppare codice esclusivamente in un ambiente locale. Ad esempio, se hai familiarità con lo sviluppo di un'applicazione n-tier, potresti disporre di un motore di database e un server Web (simili a quelli in esecuzione in produzione) in esecuzione sul tuo computer locale per fornire una capacità di test rapida, locale e isolata.

• Non richiedono alcuna modifica all'infrastruttura cloud (come gli account cloud per sviluppatori), quindi sono facili da implementare con i modelli di test esistenti. I test di emulazione hanno il vantaggio di offrire iterazioni di sviluppo locali rapide.

Tuttavia, gli emulatori presentano anche diversi svantaggi:

• Spesso sono difficili da configurare e replicare, soprattutto quando vengono utilizzati come parte di pipeline CI/CD. Questo potrebbe aumentare il carico di lavoro e la manutenzione per il personale IT o per gli sviluppatori che gestiscono le proprie installazioni software.

• Le funzionalità emulate sono APIs in genere in ritardo rispetto alle modifiche dei servizi e potrebbero ostacolare l'adozione di nuove funzionalità fino all'aggiunta del supporto.

• Gli emulatori potrebbero richiedere supporto, aggiornamenti, correzioni di bug o miglioramenti della parità delle funzionalità, che sono di responsabilità dell'autore dell'emulatore (spesso si tratta di società terze).

• I test che si basano sugli emulatori possono fornire risultati positivi a livello locale, ma potrebbero fallire nel cloud a causa delle interazioni con altri aspetti, AWS come le politiche e le quote IAM, che generalmente non vengono emulate.

• Alcuni AWS servizi non dispongono di emulatori, quindi se ti affidi solo all'emulazione, potresti non avere un'opzione di test soddisfacente per alcune parti dell'applicazione.