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à.
Sfide legate al test di applicazioni serverless
Quando si utilizzano emulatori e chiamate fittizie per eseguire i test delle applicazioni serverless 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 creati sul desktop per convalidare la logica aziendale dell'applicazione potrebbero non includere o rappresentare con precisione gli aspetti critici dei servizi cloud. I test completi non possono essere eseguiti localmente in modo isolato. Richiedono la verifica delle autorizzazioni e delle configurazioni tra più servizi.
Le sezioni seguenti descrivono le sfide che potresti incontrare durante l'implementazione di una strategia di test sul cloud.
Esempio: una funzione Lambda che 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 senza errori 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 l'identità che effettua la chiamata non avrà origine dal servizio Lambda che assume un ruolo e verrà invece utilizzata un'autenticazione segnaposto: si tratta spesso del ruolo o dell'identità utente più permissivi.
Le configurazioni di simulazione ed emulazione discusse in precedenza molto probabilmente eseguiranno test su cosa farà la funzione Lambda se la chiamata ad Amazon S3 va a buon fine (o meno). Tuttavia, questi test non riusciranno a catturare se la funzione Lambda è in grado di creare correttamente il bucket, data la configurazione della funzione. Questa configurazione è probabilmente rappresentata dall'infrastruttura come codice (IaC) per prodotti e servizi come, o Terraform. AWS CloudFormation AWS SAM HashiCorp Un possibile problema è che il ruolo assegnato alla funzione non ha una policy collegata che consenta l'azione s3:CreateBucket, e la funzione genererà sempre un errore quando viene implementata in un ambiente cloud.
Esempio: una funzione Lambda che elabora i messaggi dalla 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:DeleteMessageosqs: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.
