Come testare funzioni e applicazioni serverless

Sebbene il test delle funzioni serverless si basi su tipologie e tecniche di test consolidate, è importante tenere in considerazione la possibilità di effettuare test sulle applicazioni serverless nella loro interezza. I test basati sul cloud forniranno la misura più accurata della qualità sia delle funzioni sia delle applicazioni serverless.

Un'architettura applicativa serverless include servizi gestiti che forniscono funzionalità applicative critiche tramite chiamate API. Pertanto, è fondamentale che il ciclo di sviluppo preveda test automatici in grado di verificare il corretto funzionamento dell'interazione tra le funzioni e i servizi.

Se non crei test basati sul cloud, potresti riscontrare problemi dovuti alle differenze tra l'ambiente locale e quello implementato. Il processo di integrazione continua dovrebbe eseguire test su un insieme di risorse con provisioning nel cloud prima di promuovere il codice nell'ambiente di implementazione successivo, come quello di controllo qualità (QA), staging o produzione.

Continua a leggere questa breve guida per scoprire le strategie di test per le applicazioni serverless oppure visita il repository Serverless Test Samples per approfondire esempi pratici, specifici per il linguaggio e il runtime selezionati.

Per i test in ambito serverless, è necessario scrivere test unitari, test di integrazione e test end-to-end.

• Test unitari: vengono eseguiti su un blocco di codice isolato. Ad esempio, possono essere utilizzati per verificare la logica aziendale per calcolare le spese di spedizione in base a un articolo e a una destinazione specifici.

• Test di integrazione: coinvolgono due o più componenti o servizi che interagiscono, in genere in un ambiente cloud. Ad esempio, possono essere utilizzati per verificare che una funzione elabori gli eventi di una coda.

• E nd-to-end test: test che verificano il comportamento in un'intera applicazione. Ad esempio, possono essere utilizzati per verificare che l'infrastruttura sia configurata correttamente e che gli eventi fluiscano tra i servizi come previsto per registrare l'ordine di un cliente.

Obiettivi aziendali specifici

Le verifiche delle soluzioni serverless possono richiedere un po' più di tempo per configurare test in grado di analizzare le interazioni basate sugli eventi tra i servizi. Durante la lettura della presente guida, tieni a mente i seguenti aspetti pratici per l'azienda:

• Aumenta la qualità della tua applicazione

• Riduci il tempo necessario per creare funzionalità e correggere bug

La qualità di un'applicazione dipende dai test condotti per verificarne la funzionalità in vari scenari. Per migliorare la qualità della tua applicazione, è consigliabile valutare attentamente gli scenari aziendali e automatizzare i relativi test, eseguendoli sui servizi cloud.

Rilevare i bug del software e i problemi di configurazione durante un ciclo di sviluppo iterativo può avere un impatto minimo sui costi e sulla pianificazione. Se i problemi non vengono rilevati durante lo sviluppo, la ricerca e la risoluzione in fase di produzione richiede un maggiore impegno da parte di più persone.

Una strategia di test in ambito serverless ben pianificata aumenterà la qualità del software e migliorerà i tempi di iterazione, verificando che le applicazioni e le funzioni Lambda funzionino come previsto in un ambiente cloud.

Cosa testare

Ti consigliamo di adottare una strategia di test che verifichi i comportamenti dei servizi gestiti, la configurazione del cloud, le policy di sicurezza e l'integrazione con il codice per migliorare la qualità del software. I test comportamentali, noti anche come test della scatola nera, sono progettati per verificare il corretto funzionamento di un sistema senza la necessità di conoscere tutti i dettagli interni del software.

• Esegui test unitari per verificare la logica aziendale all'interno delle funzioni Lambda.

• Verifica che i servizi integrati siano effettivamente richiamati e che i parametri di input siano corretti.

• Verifica che un evento passi attraverso tutti i servizi previsti end-to-end in un flusso di lavoro.

Nell'architettura tradizionale basata su server, i team spesso definiscono l'ambito di test andando a includere solo il codice che viene eseguito sul server applicativo. Altri componenti, servizi o dipendenze spesso sono considerati esterni e non possono essere testati.

Le applicazioni serverless abitualmente sono costituite da piccole unità di lavoro, come le funzioni Lambda che recuperano prodotti da un database, elaborano elementi da una coda o ridimensionano un'immagine nell'archiviazione. Ogni componente viene eseguito nel proprio ambiente. Probabilmente, i team saranno responsabili di molte di queste piccole unità all'interno di una singola applicazione.

Alcune funzionalità delle applicazioni possono essere delegate interamente a servizi gestiti come Amazon S3 o create senza utilizzare alcun codice sviluppato internamente. Non è necessario testare questi servizi gestiti, ma è necessario testare l'integrazione con questi servizi.

Come testare le soluzioni serverless

Probabilmente hai familiarità con i test delle applicazioni implementate in locale: si scrivono test che vengono eseguiti su codice completamente in esecuzione sul proprio sistema operativo desktop o all'interno di container. Ad esempio, è possibile richiamare un componente del servizio Web locale con una richiesta e quindi formulare affermazioni sulla risposta.

Le soluzioni serverless vengono create a partire dal codice funzionale e dai servizi gestiti basati sul cloud, come code, database, bus di eventi e sistemi di messaggistica. Questi componenti sono tutti collegati tramite un'architettura basata sugli eventi, in cui i messaggi, chiamati eventi, fluiscono da una risorsa all'altra. Queste interazioni possono essere sincrone, ad esempio quando un servizio Web restituisce immediatamente i risultati, o un'azione asincrona che viene completata in un secondo momento, come l'inserimento di elementi in una coda o l'avvio di una fase del flusso di lavoro. La tua strategia di test deve includere entrambi gli scenari e testare le interazioni tra i servizi. Per le interazioni asincrone, potrebbe essere necessario rilevare effetti indesiderati nei componenti a valle che potrebbero non essere immediatamente osservabili.

La replica di un intero ambiente cloud, tra cui code, tabelle di database, bus di eventi, policy di sicurezza e altro ancora, non è un metodo pratico. Incontrerai inevitabilmente problemi dovuti alle differenze tra il tuo ambiente locale e gli ambienti implementati nel cloud. Le discrepanze tra i tuoi ambienti aumenteranno il tempo necessario per riprodurre e correggere i bug.

Nelle applicazioni serverless, i componenti dell'architettura solitamente esistono interamente nel cloud, quindi per sviluppare funzionalità e correggere bug è necessario eseguire test su codice e servizi nel cloud.

Tecniche di test

Nella realtà, per aumentare la qualità delle tue soluzioni, la tua strategia di test includerà probabilmente un mix di tecniche diverse. Utilizzerai test interattivi rapidi per eseguire il debug delle funzioni nella console, test unitari automatici per verificare la logica aziendale isolata, verifiche delle chiamate a servizi esterni con mock e test occasionali su emulatori che imitano un servizio.

• Test nel cloud: consente di implementare l'infrastruttura e il codice per eseguire test utilizzando effettivamente servizi, policy di sicurezza, configurazioni e parametri specifici dell'infrastruttura. I test basati sul cloud forniscono la misura più accurata della qualità del codice.

  Il debug di una funzione nella console è un modo rapido per eseguire test nel cloud. È possibile scegliere da una raccolta di esempi di eventi di test o creare un evento personalizzato per testare una funzione in modo isolato. Tramite la console puoi anche condividere gli eventi di test con il tuo team.

  Per automatizzare i test nel ciclo di vita dello sviluppo e della realizzazione, dovrai eseguire i test all'esterno della console. Per le strategie e le risorse di automazione, consulta le sezioni relative ai test per linguaggi specifici nella presente guida.

• Test con mock (chiamati anche fake): i mock sono oggetti all'interno del codice che simulano e sostituiscono un servizio esterno. I mock forniscono un comportamento predefinito per verificare le chiamate e i parametri del servizio. Un fake (o "falso") è un'implementazione fittizia che utilizza scorciatoie per semplificare o migliorare le prestazioni. Ad esempio, un oggetto di accesso ai dati falso potrebbe restituire dati da un datastore in memoria. I mock possono simulare e semplificare dipendenze complesse, ma possono anche portare a più mock per sostituire le dipendenze nidificate.

• Test con emulatori: è possibile configurare applicazioni (a volte di terze parti) per simulare un servizio cloud nel proprio ambiente locale. Il loro punto di forza è la velocità, tuttavia la configurazione e l'equivalenza con i servizi in fase di produzione sono il loro punto debole. Consigliamo di utilizzare gli emulatori con parsimonia.

Test nel cloud

I test nel cloud sono utili per tutte le fasi del test, inclusi test unitari, test di integrazione e test. end-to-end Quando esegui test su codice basato sul cloud che interagisce anche con i servizi basati sul cloud, ottieni la misura più accurata della qualità del tuo codice.

Un modo conveniente per eseguire una funzione Lambda nel cloud è con un evento di test nella AWS Management Console. Un evento di test è un input JSON per la funzione. Se la funzione non richiede input, l'evento può essere un documento JSON ({}) vuoto. La console fornisce eventi di esempio per una varietà di integrazioni di servizi. Dopo aver creato un evento nella console, puoi anche condividerlo con il tuo team per rendere i test più semplici e coerenti.

Scopri come eseguire il debug di una funzione di esempio nella console.

Nota

Sebbene l'esecuzione delle funzioni nella console sia un modo rapido per eseguire il debug, l'automazione dei cicli di test è essenziale per aumentare la qualità delle applicazioni e la velocità di sviluppo.

Gli esempi di automazione dei test sono disponibili nel repository Serverless Test Samples. La seguente linea di comando esegue un esempio di test di integrazione Python automatizzato:

python -m pytest -s tests/integration -v

Sebbene il test venga eseguito localmente, interagisce con le risorse basate sul cloud. Queste risorse sono state distribuite utilizzando lo strumento a riga di AWS SAM comando AWS Serverless Application Model and. Il codice di test recupera innanzitutto gli output dello stack implementato, che includono l'endpoint API, la funzione ARN e il ruolo di sicurezza. Successivamente, il test invia una richiesta all'endpoint API, che risponde con un elenco di bucket Amazon S3. Questo test viene eseguito interamente su risorse basate sul cloud per verificare che tali risorse siano implementate e protette e che funzionino come previsto.

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-west-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-west-2:1234567890:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::1234567890:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-west-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

I test nel cloud offrono i seguenti vantaggi per lo sviluppo di applicazioni native del cloud:

• Puoi testare ogni servizio disponibile.

• Utilizzi sempre le API del servizio e i valori restituiti più recenti.

• Un ambiente di test cloud somiglia molto al tuo ambiente di produzione.

• I test possono verificare policy di sicurezza, Service Quotas, configurazioni e parametri specifici dell'infrastruttura.

• Ogni sviluppatore può creare rapidamente uno o più ambienti di test nel cloud.

• I test nel cloud aumentano le probabilità che il codice venga eseguito correttamente in produzione.

I test nel cloud presentano alcuni svantaggi. L'aspetto negativo più evidente dei test nel cloud è che le implementazioni in ambienti cloud richiedono in genere più tempo rispetto alle implementazioni in ambienti desktop locali.

Fortunatamente, strumenti come AWS Serverless Application Model (AWS SAM) Accelerate, la modalità watch AWS Cloud Development Kit (AWS CDK) e SST (di terze parti) riducono la latenza associata alle iterazioni di implementazione nel cloud. Questi strumenti possono monitorare l'infrastruttura e il codice e implementare automaticamente aggiornamenti incrementali nell'ambiente cloud.

Nota

Scopri come creare un'infrastruttura come codice nella Serverless Developer Guide per saperne di più su, e. AWS Serverless Application Model AWS CloudFormation AWS Cloud Development Kit (AWS CDK)

A differenza dei test locali, i test nel cloud richiedono risorse aggiuntive che possono comportare costi di servizio. La creazione di ambienti di test isolati può aumentare il carico di lavoro per i DevOps team, specialmente nelle organizzazioni con controlli rigorosi su account e infrastruttura. Tuttavia, quando si lavora con scenari infrastrutturali complessi, il costo in termini di tempo degli sviluppatori per configurare e gestire un ambiente locale complesso potrebbe essere simile (o più alto) rispetto all'utilizzo di ambienti di test usa e getta creati con gli strumenti di automazione Infrastructure as Code.

I test nel cloud, anche alla luce di queste considerazioni, restano il modo migliore per garantire la qualità delle soluzioni serverless.

Test con mock

Il test con mock è una tecnica in cui crei oggetti sostitutivi nel tuo codice per simulare il comportamento di un servizio cloud.

Ad esempio, puoi scrivere un test che utilizza un mock del servizio Amazon S3 che restituisce una risposta specifica ogni volta che viene chiamato CreateObjectil metodo. Quando viene eseguito un test, il mock restituisce quella risposta programmata senza chiamare Amazon S3 o altri endpoint del servizio.

Gli oggetti fittizi (mock) sono spesso generati da un framework fittizio per ridurre gli sforzi necessari per lo sviluppo. Alcuni framework fittizi sono generici e altri sono progettati specificamente per gli AWS SDK, come Moto, una libreria Python per simulare servizi e risorse. AWS

Ricorda che gli oggetti fittizi (mock) differiscono dagli emulatori in quanto i mock vengono generalmente creati o configurati da uno sviluppatore come parte del codice di test, mentre gli emulatori sono applicazioni autonome che espongono le funzionalità allo stesso modo dei sistemi che emulano.

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

• I mock possono simulare servizi di terze parti che sfuggono al controllo dell'applicazione, come API e provider di software as a service (SaaS), senza bisogno di accedere direttamente a tali servizi.

• I mock sono utili per testare le condizioni di errore, soprattutto quando tali condizioni sono difficili da simulare, come un'interruzione del servizio.

• Una volta configurato, il mock consente di eseguire rapidamente test locali.

• 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 con mock possono reagire più rapidamente. Utilizzando un framework fittizio generico, puoi simulare 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.

• I mock devono essere scritti, configurati e gestiti dagli sviluppatori, aumentando le loro responsabilità.

• Potrebbe essere necessario avere accesso al cloud per comprendere le API e restituire i valori dei servizi.

• I mock possono essere difficili da mantenere. Quando le firme delle API cloud fittizie cambiano o gli schemi dei valori restituiti evolvono, è necessario aggiornare i mock. I mock richiedono aggiornamenti anche se si estende la logica dell'applicazione per effettuare chiamate a nuove API.

• I test che utilizzano mock potrebbero avere un esito positivo negli ambienti desktop ma fallire nel cloud. I risultati potrebbero non corrispondere all'API corrente. La configurazione e le quote del servizio non possono essere testate.

• I framework fittizi sono limitati nel testare o rilevare le limitazioni delle quote o delle policy di AWS Identity and Access Management (IAM). Sebbene i mock siano più efficaci per simulare quando l'autorizzazione viene negata o quando viene superata una quota, i test non possono determinare quale risultato si verificherà effettivamente in un ambiente di produzione.

Test con emulazione

Gli emulatori sono in genere un'applicazione eseguita localmente che imita un servizio di produzione. AWS

Gli emulatori dispongono di API simili alle loro controparti cloud e forniscono valori di ritorno simili. Possono anche simulare cambiamenti di stato avviati dalle chiamate API. Ad esempio, è possibile AWS SAM eseguire una funzione con AWS SAM local per emulare il servizio Lambda in modo da poter richiamare rapidamente una funzione. Per ulteriori informazioni, consulta la sezione AWS SAM locale nella Guida per gli sviluppatori di AWS Serverless Application Model .

I vantaggi dei test con gli emulatori sono molteplici:

• Gli emulatori possono facilitare iterazioni e test di sviluppo locale rapidi.

• Gli emulatori offrono un ambiente familiare per gli sviluppatori abituati a sviluppare codice 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.

• Gli emulatori 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 con emulatori presentano i seguenti svantaggi:

• Gli emulatori possono essere difficili da configurare e replicare, soprattutto se utilizzati nelle pipeline CI/CD. Ciò può contribuire ad aumentare il carico di lavoro del personale IT o degli sviluppatori che gestiscono il proprio software.

• Le funzionalità e le API emulate sono in genere in ritardo rispetto agli aggiornamenti del servizio. Ciò può causare errori perché il codice testato non corrisponde all'API effettiva e impedisce l'adozione di nuove funzionalità.

• Gli emulatori richiedono miglioramenti in termini di supporto, aggiornamenti, correzioni di bug e parità delle funzionalità. Questi sono di responsabilità dell'autore dell'emulatore, che potrebbe essere una società terza.

• I test che si basano sugli emulatori possono fornire risultati positivi a livello locale, ma restituire un esito negativo nel cloud a causa delle policy di sicurezza in fase di produzione, delle configurazioni tra servizi o del superamento delle quote Lambda.

• Molti AWS servizi non dispongono di emulatori disponibili. È importante considerare che, se ci si affida all'emulazione, potrebbe non essere disponibile un'opzione di test soddisfacente per alcune parti dell'applicazione.

Best practice

Le sezioni seguenti forniscono consigli per testare correttamente le applicazioni serverless.

Puoi trovare esempi pratici di test e automazione dei test nel repository Serverless Test Samples.

Dai priorità ai test nel cloud

I test nel cloud sono un'opzione molto valida per garantire la copertura dei test più affidabile, accurata e completa. L'esecuzione di test nel contesto del cloud controllerà in modo completo non solo la logica aziendale, ma anche le policy di sicurezza, le configurazioni dei servizi, le quote, i valori restituiti e le firme delle API più aggiornati.

Struttura il tuo codice per la testabilità

Semplifica i test e le funzioni Lambda separando il codice specifico di Lambda dalla logica aziendale principale.

Il gestore delle funzioni Lambda deve essere un adattatore agile in grado di acquisire i dati degli eventi e trasmettere solo i dettagli importanti ai metodi della logica aziendale. Con questa strategia, puoi eseguire test completi sulla tua logica aziendale senza preoccuparti dei dettagli specifici di Lambda. Le tue funzioni AWS Lambda non dovrebbero richiedere la configurazione di un ambiente complesso o una grande quantità di dipendenze per creare e inizializzare il componente sottoposto a test.

In generale, è consigliabile scrivere un gestore che estrae e convalida i dati dagli eventi e dagli oggetti di contesto in entrata, per poi inviare tale input ai metodi che eseguono la logica aziendale.

Accelera i cicli di feedback sullo sviluppo

Esistono strumenti e tecniche per accelerare i cicli di feedback sullo sviluppo. Ad esempio, AWS SAM Accelerate e AWS CDK watch mode riducono entrambi il tempo necessario per aggiornare gli ambienti cloud.

Gli esempi presenti nel repository GitHub Serverless Test Samples esplorano alcune di queste tecniche.

Inoltre, ti consigliamo di creare e testare le risorse cloud il prima possibile durante lo sviluppo, anziché solo dopo aver controllato il codice sorgente. Questa pratica consente di accelerare l'esplorazione e la sperimentazione durante lo sviluppo di soluzioni. Inoltre, l'automazione dell'implementazione da una macchina di sviluppo ti aiuta a scoprire i problemi di configurazione del cloud più rapidamente e riduce gli sprechi di tempo per gli aggiornamenti e i processi di revisione del codice.

Concentrati sui test di integrazione

Quando si sviluppano applicazioni con Lambda, una buona pratica è quella di testare i componenti insieme.

I test eseguiti su due o più componenti architettonici sono chiamati test di integrazione. L'obiettivo dei test di integrazione è comprendere non solo come verrà eseguito il codice tra i componenti, ma anche come si comporterà l'ambiente che ospita il codice. nd-to-end I test E sono tipi speciali di test di integrazione che verificano i comportamenti in un'intera applicazione.

Per creare test di integrazione, implementa la tua applicazione in un ambiente cloud. Questa operazione può essere eseguita da un ambiente locale o tramite una pipeline CI/CD. Quindi, scrivi dei test per esercitare il sistema sottoposto a test (SUT) e convalidare il comportamento previsto.

Ad esempio, il sistema sottoposto a test potrebbe essere un'applicazione che utilizza Gateway API, Lambda e DynamoDB. Un test potrebbe effettuare una chiamata HTTP sintetica a un endpoint API Gateway e verificare che la risposta includa il payload previsto. Questo test verifica che il codice AWS Lambda sia corretto e che ogni servizio sia configurato correttamente per gestire la richiesta, incluse le autorizzazioni IAM tra di loro. Inoltre, è possibile progettare un test in cui vengano scritti record di varie dimensioni per verificare che le Service Quotas, come la dimensione massima dei record in DynamoDB, siano impostate correttamente.

Crea ambienti di test isolati

In genere, i test nel cloud richiedono ambienti di sviluppo isolati, in modo che test, dati ed eventi non si sovrappongano.

Un approccio consiste nel fornire a ogni sviluppatore un account dedicato. AWS Ciò eviterà i conflitti relativi alla denominazione delle risorse che possono verificarsi quando più sviluppatori lavorano a una base di codice condivisa, tentano di implementare risorse o richiamano un'API.

I processi di test automatizzati dovrebbero creare risorse con un nome univoco per ogni stack. Ad esempio, puoi impostare script o file di configurazione TOML in modo che i comandi AWS SAM CLI sam deploy o sam sync specifichino automaticamente uno stack con un prefisso univoco.

In alcuni casi, gli sviluppatori condividono un account. AWS Ciò può essere dovuto alla presenza di risorse nello stack che sono dispendiose in termini di gestione o di provisioning e configurazione. Ad esempio, un database può essere condiviso per semplificare la configurazione e il seeding dei dati in modo corretto.

Se gli sviluppatori condividono un account, è necessario stabilire dei limiti per identificare la proprietà ed eliminare le sovrapposizioni. Un modo per farlo è anteporre ai nomi degli stack gli ID utente degli sviluppatori. Un altro approccio comune è quello di configurare stack basati su rami di codice. Grazie ai confini dei rami, gli ambienti sono isolati, ma gli sviluppatori possono comunque condividere risorse, come un database relazionale. Questo approccio è una procedura consigliata quando gli sviluppatori lavorano su più di un ramo alla volta.

I test nel cloud sono utili per tutte le fasi del test, inclusi test unitari, test di integrazione e end-to-end test. Mantenere un isolamento adeguato è essenziale, ma è comunque necessario che l'ambiente di controllo qualità (QA) assomigli il più possibile all'ambiente di produzione. Per questo motivo, i team aggiungono processi di controllo delle modifiche per gli ambienti QA.

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 e implementare controlli di sicurezza con privilegi minimi per proteggere i dati sensibili. I carichi di lavoro hanno delle quote assegnate. Non è auspicabile che i test consumino le quote allocate per la produzione (rischio di effetto noisy neighbor) o che abbiano accesso ai dati dei clienti. I test di carico sono un'altra attività da isolare dallo stack di produzione.

In tutti i casi, gli ambienti devono essere configurati con avvisi e controlli per evitare spese inutili. Ad esempio, è possibile limitare il tipo, il livello o la dimensione delle risorse che possono essere create e impostare avvisi e-mail quando i costi stimati superano una determinata soglia.

Usa i mock per una logica aziendale isolata

I framework fittizi sono uno strumento prezioso per scrivere test unitari rapidi. Questi sono particolarmente utili quando i test riguardano logiche aziendali interne complesse, come calcoli o simulazioni matematiche o finanziarie. Cerca test unitari che prevedono un gran numero di casi di test o varianti di input, in cui tali input non modificano lo schema o il contenuto delle chiamate ad altri servizi cloud.

Il codice verificato dai test unitari con mock dovrebbe essere verificato anche dai test nel cloud. Questa operazione è consigliata perché l'ambiente su un laptop per sviluppatori o una macchina di compilazione potrebbe essere configurato in modo diverso rispetto a un ambiente di produzione nel cloud. Ad esempio, le funzioni Lambda potrebbero utilizzare più memoria o impiegare più tempo rispetto a quanto allocato quando vengono eseguite con determinati parametri di input. Oppure il codice potrebbe includere variabili di ambiente non configurate o che non sono state configurate allo stesso modo, e le differenze potrebbero causare un comportamento diverso o un errore del codice.

Il vantaggio dei mock è minore per i test di integrazione, poiché il livello di impegno richiesto per implementare i mock necessari aumenta in proporzione al numero di punti di connessione. nd-to-end I test elettronici non dovrebbero utilizzare simulazioni, poiché questi test generalmente si occupano di stati e logiche complesse che non possono essere facilmente simulate con framework fittizi.

Infine, evita di utilizzare servizi cloud fittizi per verificare la corretta implementazione delle chiamate del servizio. Al contrario, per convalidare l'implementazione a livello di comportamento, configurazione e funzionalità, è consigliabile effettuare le chiamate ai servizi cloud direttamente nell'ambiente cloud.

Utilizza gli emulatori con parsimonia

Gli emulatori possono essere utili in alcuni casi d'uso, ad esempio per un team di sviluppo con accesso a Internet limitato, inaffidabile o lento. Tuttavia, nella maggior parte dei casi, assicurati di usare gli emulatori con parsimonia.

Evitando gli emulatori, sarai in grado di creare e innovare con le funzionalità di servizio più recenti e le API aggiornate. Non rischierai di dover aspettare che i fornitori rilascino le versioni necessarie per raggiungere la parità di funzionalità. Ridurrai le spese iniziali e correnti per l'acquisto e la configurazione di più sistemi di sviluppo e macchine di compilazione. Inoltre, eviterai il problema che molti servizi cloud semplicemente non dispongono di emulatori. Pertanto, se la strategia di test dipende dall'emulazione, non si potranno utilizzare tali servizi (e, di conseguenza, occorreranno soluzioni alternative potenzialmente più costose), oppure si produrranno codice e configurazioni non testati adeguatamente.

Quando si utilizza l'emulazione per i test, è comunque necessario eseguire il test nel cloud per verificare la configurazione e testare le interazioni con i servizi cloud che possono essere simulate o ricorrere all'utilizzo di mock solo in un ambiente emulato.

Problematiche legate ai test locali

Quando si utilizzano emulatori e chiamate fittizie per eseguire i test sul desktop locale, è possibile che si verifichino incongruenze nei test man mano che il codice passa da un ambiente all'altro nella pipeline CI/CD. I test unitari impiegati per convalidare la logica aziendale dell'applicazione sul desktop potrebbero non testare con precisione gli aspetti critici dei servizi cloud.

Gli esempi seguenti forniscono alcuni casi a cui prestare attenzione quando si eseguono test localmente con mock ed emulatori:

Esempio: la funzione Lambda crea un bucket S3

Se la logica di una funzione Lambda dipende dalla creazione di un bucket S3, un test completo dovrebbe confermare che Amazon S3 è stato chiamato e che il bucket è stato creato correttamente.

• In una configurazione di test con mock, potresti simulare una risposta con esito positivo e potenzialmente aggiungere un caso di test per gestire una risposta non esito negativo.

• In uno scenario di test di emulazione, è possibile chiamare l'CreateBucketAPI, ma è necessario tenere presente che l'identità che effettua la chiamata locale non avrà origine dal servizio Lambda. L'identità che effettua la chiamata non assumerà un ruolo di sicurezza come nel cloud, quindi verrà utilizzata invece un'autenticazione segnaposto, possibilmente con un ruolo o un'identità utente più permissivi che saranno diversi quando vengono eseguiti nel cloud.

Le configurazioni di mock ed emulazione verificheranno cosa farà la funzione Lambda se chiama Amazon S3; tuttavia, tali test non verificheranno che la funzione Lambda, così come configurata, sia in grado di creare correttamente il bucket Amazon S3. È necessario assicurarsi che al ruolo assegnato alla funzione sia associata una policy di sicurezza che consenta alla funzione di eseguire l'operazione s3:CreateBucket. In caso contrario, la funzione probabilmente genererà un errore qualora implementata in un ambiente cloud.

Esempio: una funzione Lambda elabora i messaggi da una coda Amazon SQS

Se una coda Amazon SQS è l'origine di una funzione Lambda, un test completo deve verificare che quando un messaggio viene inserito in una coda la funzione Lambda venga richiamata correttamente.

I test di emulazione e i test con mock sono generalmente impostati per eseguire direttamente il codice della funzione Lambda e per simulare l'integrazione con Amazon SQS passando un payload di eventi JSON (o un oggetto deserializzato) come input del gestore della funzione.

I test locali che simulano l'integrazione con Amazon SQS verificheranno cosa farà la funzione Lambda quando viene chiamata da Amazon SQS con un determinato payload, ma non verificheranno che Amazon SQS richiami correttamente la funzione Lambda quando viene implementata in un ambiente cloud.

Di seguito troverai alcuni esempi di problemi di configurazione che potresti riscontrare con Amazon SQS e Lambda:

• Il timeout di visibilità di Amazon SQS è troppo basso e comporta più chiamate quando ne era prevista una sola.

• Il ruolo di esecuzione della funzione Lambda non consente la lettura di messaggi dalla coda (tramite sqs:ReceiveMessage, sqs:DeleteMessage o sqs:GetQueueAttributes).

• L'evento di esempio passato alla funzione Lambda supera la quota relativa alla dimensione dei messaggi di Amazon SQS. Pertanto, il test non è valido perché Amazon SQS non sarebbe mai in grado di inviare un messaggio di tali dimensioni.

Come mostrano questi esempi, con molta probabilità si otterranno risultati inattendibili dai test che riguardano la logica aziendale ma non le configurazioni tra i servizi cloud.

Domande frequenti

Ho una funzione Lambda che esegue calcoli e restituisce un risultato senza chiamare altri servizi. Devo davvero testarla nel cloud?

Sì. Le funzioni Lambda hanno parametri di configurazione che possono modificare l'esito del test. Tutto il codice della funzione Lambda dipende dal timeout e dalle impostazioni di memoria, il che potrebbe causare il fallimento della funzione se tali impostazioni non sono impostate correttamente. Le policy Lambda consentono anche la registrazione standard dell'output su Amazon. CloudWatch Anche se il codice non chiama CloudWatch direttamente, è necessaria l'autorizzazione per abilitare la registrazione. Questa autorizzazione richiesta non può essere simulata o emulata con precisione.

In che modo i test nel cloud possono contribuire ai test unitari? Se sono nel cloud e si connettono ad altre risorse, non si tratta di test di integrazione?

Definiamo test unitari quei test che operano su componenti architettonici isolati, ma ciò non impedisce di includere componenti che possono richiamare altri servizi o di utilizzare alcune comunicazioni di rete.

Molte applicazioni serverless dispongono di componenti architettonici che possono essere testati in modo isolato, anche nel cloud. Un esempio può essere quello di una funzione Lambda che accetta l'input, elabora i dati e invia un messaggio a una coda Amazon SQS. Un test unitario di questa funzione verificherebbe probabilmente se i valori di input determinano la presenza di determinati valori nel messaggio in coda.

Prendi in considerazione un test scritto utilizzando lo schema Arrange, Act, Assert (organizzazione, azione, affermazione):

• Arrange: alloca le risorse (una coda per ricevere messaggi e la funzione sottoposta a test).

• Act: chiama la funzione sottoposta a test.

• Assert: recupera il messaggio inviato dalla funzione e convalida l'output.

Un approccio di test con mock implicherebbe la simulazione della coda con un oggetto fittizio in corso di elaborazione e la creazione di un'istanza durante il processo della classe o del modulo che contiene il codice della funzione Lambda. Durante la fase Assert, il messaggio in coda verrebbe recuperato dall'oggetto fittizio.

In un approccio basato sul cloud, il test creerebbe una coda Amazon SQS ai fini del test e implementerebbe la funzione Lambda con variabili di ambiente configurate per utilizzare la coda Amazon SQS isolata come destinazione di output. Dopo aver eseguito la funzione Lambda, il test recupererebbe il messaggio dalla coda di Amazon SQS.

Il test basato sul cloud eseguirebbe lo stesso codice, affermerebbe lo stesso comportamento e convaliderebbe la correttezza funzionale dell'applicazione. Tuttavia, avrebbe l'ulteriore vantaggio di poter convalidare le impostazioni della funzione Lambda: il ruolo IAM, le policy IAM e le impostazioni di timeout e di memoria della funzione.

Risorse e passaggi successivi

Utilizza le seguenti risorse per ottenere ulteriori informazioni ed esplorare esempi pratici di test.

Implementazioni di esempio

Il repository Serverless Test Samples su GitHub contiene esempi concreti di test che seguono i modelli e le migliori pratiche descritti in questa guida. Il repository contiene codice di esempio e procedure dettagliate dei processi di test con mock, emulazione e cloud descritti nelle sezioni precedenti. Usa questo repository per aggiornarti sulle ultime linee guida per i test serverless di. AWS

Approfondimenti

Visita Serverless Land per accedere ai blog, ai video e ai corsi di formazione più recenti sulle tecnologie serverless. AWS

Si consiglia di leggere anche i seguenti post del AWS blog:

• Accelerazione dello sviluppo serverless con AWS SAM Accelerate (AWS post sul blog)

• Aumentare la velocità di sviluppo con CDK Watch (AWS post sul blog)

• Simulazione delle integrazioni di servizi con AWS Step Functions Local (post sul blog)AWS

• Guida introduttiva al test di applicazioni serverless (post sul blog)AWS

Strumenti

• AWS SAM — Test e debug di applicazioni serverless

• AWS SAM — Integrazione con test automatici

• Lambda: Test delle funzioni Lambda nella console Lambda