Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Come eseguire test di funzioni e applicazioni serverless

Il test delle funzioni serverless utilizza tipi e tecniche di test tradizionali, ma è necessario considerare anche il test delle applicazioni serverless nel loro insieme. Cloud-based i test forniscono la misura più accurata della qualità sia delle funzioni che 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 serverless, è comunque necessario scrivere test unitari, di integrazione e end-to-end.

Obiettivi aziendali specifici

Il test delle soluzioni serverless potrebbe richiedere più tempo per la configurazione. È necessario verificare le interazioni tra i servizi basate sugli eventi. Mentre leggi questa guida, tieni a mente questi motivi aziendali pratici:

La qualità di un'applicazione dipende dal test di molti scenari. Considerate i vostri scenari aziendali e automatizzate i test da eseguire sui servizi cloud. Ciò aumenta la qualità della tua applicazione.

I bug e i problemi di configurazione costano meno se rilevati nelle prime fasi del ciclo di sviluppo. Problemi che passano inosservati fino a quando la produzione non richiede più impegno e più persone per essere risolti.

Una buona strategia di test serverless migliora la qualità del software e accelera le iterazioni. Verifica che le funzioni e le applicazioni Lambda funzionino come previsto nel cloud.

Cosa testare

Consigliamo una strategia di test che verifichi i comportamenti dei servizi gestiti, la configurazione del cloud, le politiche di sicurezza e l'integrazione con il codice. Il test comportamentale, noto anche come black box test, verifica che un sistema funzioni come previsto senza conoscerne i componenti interni.

Nell'architettura tradizionale basata su server, i team spesso testano solo il codice che viene eseguito sul server delle applicazioni. Considerano gli altri componenti, servizi o dipendenze esterni e non compresi nell'ambito di applicazione.

Le applicazioni serverless sono costituite da piccole unità di lavoro. Gli esempi includono le funzioni Lambda che recuperano prodotti da un database, elaborano elementi da una coda o ridimensionano un'immagine in archivio. Ogni componente viene eseguito nel proprio ambiente. I team gestiscono molte di queste piccole unità all'interno di un'unica applicazione.

Alcune funzionalità possono essere gestite interamente da servizi gestiti come Amazon S3 o create senza codice personalizzato. Non è necessario testare questi servizi gestiti. Tuttavia, è necessario verificare in che modo il codice si integra con essi.

Come testare le soluzioni serverless

Probabilmente sai come testare le applicazioni distribuite localmente. Si scrivono test sul codice sul desktop o all'interno di contenitori. Ad esempio, potresti chiamare un servizio web locale e quindi controllare la risposta.

Le soluzioni serverless utilizzano il codice funzione e i servizi gestiti basati sul cloud, come code, database, bus di eventi e sistemi di messaggistica. Questi componenti si connettono tramite un'architettura basata sugli eventi, in cui i messaggi, chiamati eventi, fluiscono da una risorsa all'altra. Alcune interazioni sono sincrone, come un servizio web che restituisce immediatamente i risultati.

Altre sono asincrone, come l'inserimento di elementi in una coda o l'avvio di una fase del flusso di lavoro. La tua strategia di test deve coprire entrambi i tipi e testare le interazioni tra i servizi. Per le interazioni asincrone, potrebbe essere necessario rilevare effetti collaterali nei componenti a valle che non sono immediatamente visibili.

Non è possibile replicare completamente un ambiente cloud a livello locale. Ciò include code, tabelle del database, bus di eventi e politiche di sicurezza. Le differenze tra ambienti locali e cloud causano problemi. Queste differenze aumentano il tempo necessario per la riproduzione e la correzione dei bug.

Nelle applicazioni serverless, i componenti sono presenti interamente nel cloud. I test rispetto al codice e ai servizi cloud sono necessari per sviluppare funzionalità e correggere i bug.

Tecniche di test

La tua strategia di test probabilmente include un mix di tecniche. Si utilizzano test interattivi rapidi per eseguire il debug delle funzioni nella console. Si scrivono unit test automatici per verificare la logica aziendale. Le chiamate a servizi esterni vengono verificate con simulazioni. Puoi anche testare emulatori che imitano un servizio.

Test nel cloud

I test nel cloud sono utili per tutte le fasi dei test: test unitari, test di integrazione e test end-to-end. I test eseguiti su codice e servizi basati su cloud forniscono la misura più accurata della qualità del codice.

Un modo semplice per eseguire una funzione Lambda nel cloud è con un evento di test nel. Console di gestione AWS Un evento di test è un input JSON per la funzione. Se la tua funzione non richiede input, l'evento può essere un documento JSON vuoto. ({}) La console fornisce eventi di esempio per molte integrazioni di servizi. Puoi condividere gli eventi con il tuo team per semplificare i test.

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

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 risorse basate sul cloud. Queste risorse sono state distribuite utilizzando lo strumento da riga di AWS SAM comando AWS Serverless Application Model and. Il codice di test recupera innanzitutto gli output dello stack distribuito, come l'endpoint API, la funzione ARN e il ruolo di sicurezza.

Quindi, invia una richiesta all'endpoint API. La risposta contiene un elenco di bucket Amazon S3. Questo test viene eseguito su risorse basate sul cloud per verificare che siano distribuite, protette e funzionanti.

========================= 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-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

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

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012: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-east-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:

I test nel cloud presentano alcuni aspetti negativi. Le implementazioni cloud richiedono in genere più tempo rispetto alle distribuzioni desktop locali.

Strumenti come AWS Serverless Application Model (AWS SAM) Accelerate, AWS Cloud Development Kit (AWS CDK) watch mode e SST (di terze parti) riducono questa latenza. Questi strumenti monitorano l'infrastruttura e il codice, quindi implementano automaticamente gli aggiornamenti nell'ambiente cloud.

A differenza dei test locali, i test sul cloud utilizzano risorse che potrebbero comportare costi. Gli ambienti di test isolati potrebbero aggiungere lavoro ai tuoi DevOps team, specialmente nelle organizzazioni con severi controlli sugli account. Tuttavia, il tempo dedicato agli sviluppatori per configurare un ambiente locale complesso può costare di più rispetto all'utilizzo di ambienti cloud usa e getta creati con strumenti 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, potresti scrivere un test che utilizzi una simulazione del servizio Amazon S3. Il mock restituisce una risposta impostata ogni volta che viene chiamato il CreateObject metodo. Non chiama Amazon S3 o altri endpoint di servizio.

I framework fittizi spesso generano oggetti fittizi per te. Alcuni framework sono generici. Altri hanno come target gli AWS SDK, come Moto, una libreria Python per simulare servizi. AWS

Gli oggetti fittizi differiscono dagli emulatori. Gli sviluppatori creano dei mock come parte del codice di test. Gli emulatori sono applicazioni autonome che presentano le stesse funzionalità dei sistemi che imitano.

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

I test con mock presentano i seguenti svantaggi:

Test a livello locale utilizzando AWS SAM CLI

AWS SAMCLIUsalo per testare le tue funzioni nei contenitori Docker utilizzando lo stesso ambiente di runtime di. AWS Lambda Puoi testare la logica delle funzioni e l'elaborazione degli eventi localmente senza implementarli nel cloud. Se la tua funzione effettua chiamate API ad altre Servizi AWS, tali chiamate raggiungono AWS risorse reali.

I vantaggi del test con contenitori locali includono quanto segue:

I test con contenitori locali presentano le seguenti limitazioni:

Test con emulazione

Gli emulatori sono applicazioni eseguite localmente che simulano AWS i servizi fornendo API e valori di ritorno simili. LocalStack è un popolare strumento di emulazione che fornisce un ambiente di sviluppo locale completo per testare le integrazioni dei servizi.

LocalStack è un emulatore AWS cloud che puoi utilizzare per testare le applicazioni serverless a livello locale. Puoi testare le funzioni Lambda che si integrano con servizi come DynamoDB, Amazon S3 e Amazon SQS senza connetterti a servizi effettivi. AWS Puoi utilizzarlo LocalStack nel Toolkit for VS Code AWS .

I vantaggi dei test con gli emulatori sono molteplici:

I test con emulatori presentano i seguenti svantaggi:

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 dei test nel contesto del cloud verifica in modo completo non solo la logica aziendale ma anche le politiche di sicurezza, le configurazioni dei servizi, le quote e le firme API e i valori restituiti più aggiornati.

Struttura il tuo codice per la testabilità

Semplifica i test e le funzioni Lambda separando il codice dalla logica aziendale principale. Lambda-specific

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. Lambda-specific 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 in fase di 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 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 viene eseguito il codice tra i componenti, ma anche come si comporta l'ambiente che ospita il codice. End-to-end i test 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 CI/CD pipeline. 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, comprese le autorizzazioni IAM tra di essi. 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 In questo modo si evitano conflitti con la denominazione delle risorse che possono verificarsi quando più sviluppatori lavorano in una base di codice condivisa, tentano di distribuire risorse o richiamare 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ò potrebbe essere dovuto alla presenza di risorse nello stack costose da utilizzare o da fornire e configurare. Ad esempio, un database potrebbe essere condiviso per semplificare l'impostazione e il corretto seeding dei dati

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 di test, inclusi i test unitari, i test di integrazione e i test end-to-end. 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.

I vantaggi dei mock sono minori per i test di integrazione, poiché il livello di impegno necessario per implementare i mock necessari aumenta con il numero di punti di connessione. End-to-end i test non dovrebbero utilizzare simulazioni, poiché questi test generalmente si occupano di stati e logiche complesse che non possono essere facilmente simulati 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, puoi creare e innovare con le funzionalità di servizio più recenti e le API aggiornate. Non resterai bloccato ad aspettare le versioni dei fornitori per raggiungere la parità di funzionalità. Riduci le spese iniziali e continue per l'acquisto e la configurazione su più sistemi di sviluppo e macchine di costruzione. Inoltre, si evita il problema che molti servizi cloud semplicemente non dispongono di emulatori. Una strategia di test che dipende dall'emulazione rende impossibile utilizzare tali servizi (portando a soluzioni alternative potenzialmente più costose) o produrre codice e configurazioni non ben testati.

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 utilizzate emulatori e chiamate simulate per eseguire i test sul desktop locale, potreste riscontrare delle incongruenze nei test man mano che il codice progredisce da un ambiente all'altro nella pipeline. CI/CD I test unitari per convalidare la logica di business dell'applicazione sul desktop potrebbero non testare accuratamente 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.

Le configurazioni di simulazione ed emulazione verificano cosa fa la funzione Lambda se chiama Amazon S3; tuttavia, tali test non verificano 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, è probabile che la funzione fallisca quando viene distribuita 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 simulati sono generalmente impostati per eseguire direttamente il codice della funzione Lambda e per simulare l'integrazione di 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 di Amazon SQS verificano cosa fa la funzione Lambda quando viene richiamata da Amazon SQS con un determinato payload, ma non verifica che Amazon SQS richiami correttamente la funzione Lambda quando viene distribuita in un ambiente cloud.

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

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 dalle impostazioni di timeout e memoria, e se tali aspetti non sono impostati correttamente potrebbero causare errori della funzione.

Le policy Lambda consentono inoltre 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 è nel cloud e si connette ad altre risorse, non è un test di integrazione?

Definiamo i test unitari come test che operano su componenti architettonici in modo isolato, ma ciò non impedisce ai test di includere componenti che potrebbero chiamare altri servizi o 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):

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 su 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 politiche IAM e le impostazioni di timeout e 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 essere aggiornato sulle ultime linee guida sui 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 inoltre la lettura dei seguenti post del AWS blog:

Strumenti