Tecniche di test per applicazioni serverless

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

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 simulati potrebbero essere superati localmente ma fallire nel cloud perché simulano, anziché replicare, il comportamento di servizi reali, lasciando inosservati i problemi specifici dell'ambiente.

I framework fittizi, come gli emulatori, non sono in grado di rilevare violazioni delle policy AWS Identity and Access Management (IAM), limiti delle quote di servizio o vincoli di dimensione del payload, né attivano servizi ausiliari come Amazon AWS CloudTrail o Amazon GuardDuty che possono influire sul comportamento delle CloudWatch applicazioni in un ambiente distribuito.

Sebbene i mock siano più efficaci nel simulare ciò che farà un'applicazione quando l'autorizzazione fallisce o viene superata una quota, i test fittizi non sono in grado di determinare quale risultato si verificherà effettivamente quando il codice viene distribuito nell'ambiente di produzione.

Offrono l'ambiente più familiare per gli sviluppatori che sono abituati a sviluppare codice esclusivamente in un ambiente locale. Ad esempio, se avete dimestichezza con lo sviluppo di un'applicazione di livello n, potreste avere un motore di database e un server Web, simili a quelli in esecuzione in produzione, in esecuzione sul computer locale per fornire funzionalità di test rapide, locali e isolate.

Non richiede alcuna modifica all'infrastruttura cloud (come gli account cloud degli sviluppatori), quindi è facile da implementare con i modelli di test esistenti. I test di emulazione hanno il vantaggio di offrire iterazioni di sviluppo locali rapide.

Spesso sono difficili da configurare e replicare, soprattutto quando vengono utilizzati come parte delle CI/CD pipeline. 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 Servizi AWS non dispongono di emulatori, quindi se ti affidi solo all'emulazione, potresti non avere un'opzione di test soddisfacente per alcune parti dell'applicazione.

Puoi eseguire test nel cloud sulle funzionalità APIs e sui servizi più recenti, assicurandoti che riflettano i valori e i comportamenti restituiti più recenti mentre AWS continui a lanciare nuovi servizi e funzionalità.

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.

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.

I test nel cloud potrebbero essere meno fattibili se non disponi di un accesso a Internet ad alta velocità. 

Nei settori regolamentati, le politiche di sicurezza aziendali possono limitare l'accesso degli sviluppatori agli ambienti cloud, rendendo difficile o impossibile l'esecuzione di test sul cloud come parte di un flusso di lavoro di sviluppo locale.

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.