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à.

Best practice per testare le applicazioni serverless

Le sezioni seguenti descrivono le best practice per ottenere una copertura efficace durante il test di applicazioni serverless.

Dai priorità ai test nel cloud

Per applicazioni ben progettate, puoi utilizzare una varietà di tecniche di test per soddisfare una serie di requisiti e condizioni. Tuttavia, sulla base degli strumenti attuali, ti consigliamo di concentrarti il più possibile sui test nel cloud. Sebbene i test nel cloud possano creare latenza per gli sviluppatori, aumentare i costi e talvolta richiedere investimenti in DevOps controlli aggiuntivi, questa tecnica offre la copertura di test più affidabile, accurata e completa.

Devi avere accesso ad ambienti isolati in cui eseguire i test. Idealmente, ogni sviluppatore dovrebbe disporre di un programma dedicato Account AWS per evitare problemi di denominazione delle risorse che possono verificarsi quando più sviluppatori che lavorano sullo stesso codice cercano di distribuire o richiamare chiamate API su risorse con nomi identici. Questi ambienti devono essere configurati con avvisi e controlli adeguati 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.

Se devi condividerne una Account AWS con altri sviluppatori, i processi di test automatici dovrebbero denominare le risorse in modo univoco per ogni sviluppatore. Ad esempio, gli script di aggiornamento o i file di configurazione TOML che causano i comandi AWS SAM CLI sam deploy o sam sync possono specificare automaticamente un nome di stack che include il nome utente dello sviluppatore locale.

I test nel cloud sono utili per tutte le fasi del test, inclusi test unitari, test di integrazione e test. end-to-end

Usa dei mock se necessario

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. La creazione di test fittizi per questi scenari può migliorare i tempi di iterazione degli sviluppatori.

Il codice verificato dai test unitari che usano i test fittizi dovrebbe essere verificato anche dai test nel cloud. Ciò è necessario perché i mock sono ancora in esecuzione sul laptop o sulla macchina di compilazione di uno sviluppatore e l'ambiente potrebbe essere configurato in modo diverso rispetto a quello nel cloud. Ad esempio, il codice potrebbe includere AWS Lambda funzioni che utilizzano più memoria o richiedono più tempo di quello che Lambda è configurato per allocare quando viene eseguito con determinati parametri di input. Oppure il codice potrebbe includere variabili di ambiente che non sono configurate nello stesso modo (o non sono affatto configurate) e le differenze potrebbero causare un comportamento diverso o un errore del codice.

Non utilizzare simulazioni di servizi cloud per convalidare la corretta implementazione di tali integrazioni di servizi. Sebbene possa essere accettabile simulare un servizio cloud quando si testano altre funzionalità, è consigliabile testare le chiamate ai servizi cloud nel cloud per convalidare la configurazione e l'implementazione funzionale corrette.

I mock possono aggiungere valore ai test unitari, soprattutto quando si testano frequentemente un gran numero di casi. Questo vantaggio è ridotto 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-endi test non dovrebbero utilizzare simulazioni, poiché generalmente si occupano di stati e logiche complesse che non possono essere facilmente simulate con framework fittizi.

Comprendi i compromessi dei test di emulazione

Gli emulatori possono essere una scelta pratica per casi d'uso specifici. Ad esempio, un team di sviluppo con accesso a Internet limitato, incoerente o lento potrebbe scoprire che i test di emulazione sono il modo più affidabile per iterare sul codice prima di passare a un ambiente cloud.

Nella maggior parte delle altre circostanze, utilizza gli emulatori in modo selettivo. Quando fai molto affidamento su un emulatore, può diventare difficile incorporare nuove funzionalità di AWS servizio nei test fino a quando il fornitore dell'emulazione non rilascia un aggiornamento che garantisca la parità di funzionalità. Gli emulatori richiedono inoltre investimenti iniziali e continui per l'installazione e la configurazione dei sistemi di sviluppo e delle macchine di costruzione. Inoltre, molti servizi cloud non dispongono di emulatori; la scelta di una strategia incentrata sull'emulazione può precludere l'uso di tali servizi o produrre codice e configurazioni che non sono ben testati rispetto al comportamento reale dei servizi.

Se utilizzi i test di emulazione, completali il più possibile con i test sul cloud per verificare che siano presenti configurazioni cloud corrette e per testare le interazioni con servizi che possono essere simulati o simulati solo in un ambiente emulato.

I test di emulazione possono fornire un feedback rapido per i test unitari e, a seconda delle caratteristiche e della parità comportamentale del software di emulazione, possono supportare anche alcune integrazioni e test. end-to-end

Amplia i test attraverso i confini naturali

Man mano che le applicazioni serverless si espandono su più componenti architettonici, emergono confini naturali attorno ai sottosistemi, specialmente quando si seguono le migliori pratiche come le funzioni monouso e il disaccoppiamento basato sugli eventi. Questi limiti fungono da punti di prova efficaci in cui è possibile convalidare i contratti tra i componenti.

Identifica i confini dell'architettura

Cerca cuciture naturali nel design della tua applicazione:

Separare il codice Lambda dalla logica aziendale

Semplifica i test isolando il codice Lambda dalla logica aziendale principale. Il gestore Lambda dovrebbe fungere da sottile adattatore tra il AWS runtime e la logica dell'applicazione. Dovrebbe estrarre e convalidare i dati degli eventi e quindi delegarli a una funzione testabile che non ha dipendenze Lambda. Ciò rende la logica aziendale portabile, più facile da ragionare e semplice da testare senza simulare oggetti Lambda o configurare ambienti complessi.

Tratta i confini come contratti

Esegui i test al confine, non attraverso di esso. Convalida ciò che attraversa il limite senza richiedere l'intero sistema a valle. Questi stessi limiti fungono anche da ganci di osservabilità nella produzione. Le giunture architettoniche in cui esegui i test possono essere strumentate per il monitoraggio utilizzando Amazon CloudWatch Logs, AWS X-Ray trace ed eventi. EventBridge

Utilizza test harness per flussi di lavoro asincroni

Le applicazioni serverless si basano spesso su modelli asincroni, in cui gli eventi attivano l'elaborazione, i messaggi scorrono attraverso le code e i flussi di lavoro si estendono su più servizi senza risposte immediate. Non puoi semplicemente richiamare una funzione e controllare un valore restituito. Il risultato può apparire successivamente in un database, in un flusso di log o in un altro servizio.

Un test harness è un'infrastruttura di test implementata insieme all'applicazione per osservare e convalidare questo comportamento asincrono. I test harness in genere includono:

Il codice di test avvia un evento, attende il completamento del flusso di lavoro, quindi interroga il test harness per verificare che si sia verificato il risultato previsto.

Di seguito sono riportate le best practice:

I test harness sono particolarmente utili per i test di integrazione che convalidano i flussi di lavoro su più servizi, i end-to-end test che verificano i percorsi completi degli utenti e le architetture basate sugli eventi in cui i servizi comunicano attraverso Amazon EventBridge SNS, Amazon SQS o Amazon Kinesis.

Organizza ambienti cloud per l'isolamento degli sviluppatori

I test nel cloud richiedono ambienti isolati l'uno dall'altro. Quando gli sviluppatori condividono un unico account Account AWS, ad esempio un account di sviluppo in team, prendi in considerazione la possibilità di creare uno stack di applicazioni separato per ogni sviluppatore o ramo di funzionalità. In questo modo si isolano le risorse, si evitano le collisioni tra i nomi e si evitano contese tra le quote o problemi legati alla rumorosità dei vicini durante i test.

Utilizza AWS Systems Manager Parameter Store o strumenti simili per gestire configurazioni specifiche dello stack, come gli endpoint delle API e i nomi delle code. Per ridurre i costi, condividi risorse costose come i cluster Amazon Relational Database Service (Amazon RDS) tra stack di sviluppatori, mantenendo al contempo le risorse serverless leggere (come funzioni Lambda, fasi API Gateway e tabelle DynamoDB) isolate per stack.

Nei settori regolamentati, le politiche di sicurezza aziendali possono limitare l'accesso degli sviluppatori agli ambienti cloud, rendendo difficile l'esecuzione di test sul cloud come parte di un flusso di lavoro di sviluppo locale. In questi casi, i test di emulazione possono colmare il divario tra i test simulati locali e la convalida completa del cloud, anche se dovrebbero essere integrati dai test sul cloud ogni volta che l'accesso lo consente.

Accelera i cicli di feedback

Quando esegui i test nel cloud, utilizza strumenti e tecniche per accelerare i cicli di feedback dello sviluppo. Ad esempio, utilizza AWS SAMAWS CDK Accelerate e la modalità watch per ridurre il tempo necessario per apportare modifiche al codice in un ambiente cloud. Gli esempi presenti nel repository GitHub Serverless Test Samples esplorano alcune di queste tecniche.

Ti consigliamo inoltre di creare e testare le risorse cloud dal tuo computer locale il prima possibile durante lo sviluppo, non solo dopo il check-in per il controllo del codice sorgente. Questa pratica consente di accelerare l'esplorazione e la sperimentazione durante lo sviluppo di soluzioni. Inoltre, la capacità di automatizzare l'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 l'approvazione delle modifiche al controllo del codice sorgente.