Adozione di un approccio di sviluppo basato su test - AWS Guida prescrittiva

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

Adozione di un approccio di sviluppo basato su test

Ti consigliamo di seguire un approccio di sviluppo basato sui test (TDD) con. AWS CDK TDD è un approccio di sviluppo di software in cui si sviluppano casi di test per specificare e verificare il codice. In parole povere, per prima cosa si creano casi di test per ciascuna funzionalità e, se il test ha esito negativo, si scrive il nuovo codice per superare il test e fare in modo che sia semplice e privo di bug.

Puoi utilizzare TDD per scrivere prima il caso di test. Ciò consente di verificare l'infrastruttura con diversi vincoli di progettazione in termini di applicazione della politicy di sicurezza per le risorse e di rispetto di una convenzione di denominazione esclusiva per il progetto. L'approccio standard per testare AWS CDK le applicazioni consiste nell'utilizzare il modulo AWS CDKassertions e i framework di test più diffusi, come Jest for e/o pytest for TypeScript JavaScript Python.

Esistono due categorie di test che puoi scrivere per le tue applicazioni: AWS CDK

  • Utilizza asserzioni dettagliate per testare un aspetto specifico del CloudFormation modello generato, ad esempio «questa risorsa ha questa proprietà con questo valore». Questi test possono rilevare eventuali regressioni e sono utili anche quando vuoi sviluppare nuove funzionalità con TDD (prima scrivi un test, poi fai in modo che venga superato scrivendo un'implementazione corretta). Le asserzioni granulari sono i test che scriverai più spesso.

  • Utilizza i test snapshot per testare il modello sintetizzato CloudFormation rispetto a un modello di base memorizzato in precedenza. I test snapshot consentono di rifattorizzare liberamente, perché hai la certezza che il codice rifattorizzato funziona esattamente allo stesso modo dell'originale. Se le modifiche sono state intenzionali, puoi accettare una nuova base per i test futuri. Tuttavia, AWS CDK gli aggiornamenti possono anche causare modifiche ai modelli sintetizzati, quindi non puoi fare affidamento solo sulle istantanee per assicurarti che l'implementazione sia corretta.

Test unitario

Questa guida si concentra TypeScript specificamente sull'integrazione dei test unitari. Per abilitare i test, assicurati che il package.json file abbia le seguenti librerie: @types/jestjest, e ts-jest indevDependencies. Per aggiungere questi pacchetti, esegui il comando cdk init lib --language=typescript. Dopo aver eseguito il comando precedente, visualizzerai la struttura seguente.

Struttura dei test di unità

Il codice seguente è un esempio di package.json file abilitato con la libreria Jest.

{ ... "scripts": { "build": "npm run lint && tsc", "watch": "tsc -w", "test": "jest", }, "devDependencies": { ... "@types/jest": "27.5.2", "jest": "27.5.1", "ts-jest": "27.1.5", ... } }

Nella cartella Test, puoi scrivere il caso di test. L'esempio seguente mostra un test case per un AWS CodePipeline costrutto.

import { Stack } from 'aws-cdk-lib'; import { Template } from 'aws-cdk-lib/assertions'; import * as CodePipeline from 'aws-cdk-lib/aws-codepipeline'; import * as CodePipelineActions from 'aws-cdk-lib/aws-codepipeline-actions'; import { MyPipelineStack } from '../lib/my-pipeline-stack'; test('Pipeline Created with GitHub Source', () => { // ARRANGE const stack = new Stack(); // ACT new MyPipelineStack(stack, 'MyTestStack'); // ASSERT const template = Template.fromStack(stack); // Verify that the pipeline resource is created template.resourceCountIs('AWS::CodePipeline::Pipeline', 1); // Verify that the pipeline has the expected stages with GitHub source template.hasResourceProperties('AWS::CodePipeline::Pipeline', { Stages: [ { Name: 'Source', Actions: [ { Name: 'SourceAction', ActionTypeId: { Category: 'Source', Owner: 'ThirdParty', Provider: 'GitHub', Version: '1' }, Configuration: { Owner: { 'Fn::Join': [ '', [ '{{resolve:secretsmanager:', { Ref: 'GitHubTokenSecret' }, ':SecretString:owner}}' ] ] }, Repo: { 'Fn::Join': [ '', [ '{{resolve:secretsmanager:', { Ref: 'GitHubTokenSecret' }, ':SecretString:repo}}' ] ] }, Branch: 'main', OAuthToken: { 'Fn::Join': [ '', [ '{{resolve:secretsmanager:', { Ref: 'GitHubTokenSecret' }, ':SecretString:token}}' ] ] } }, OutputArtifacts: [ { Name: 'SourceOutput' } ], RunOrder: 1 } ] }, { Name: 'Build', Actions: [ { Name: 'BuildAction', ActionTypeId: { Category: 'Build', Owner: 'AWS', Provider: 'CodeBuild', Version: '1' }, InputArtifacts: [ { Name: 'SourceOutput' } ], OutputArtifacts: [ { Name: 'BuildOutput' } ], RunOrder: 1 } ] } // Add more stage checks as needed ] }); // Verify that a GitHub token secret is created template.resourceCountIs('AWS::SecretsManager::Secret', 1); }); );

Per avviare un test, esegui il comando npm run test nel progetto. Il test restituisce i risultati seguenti.

PASS test/codepipeline-module.test.ts (5.972 s) ✓ Code Pipeline Created (97 ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 0 total Time: 6.142 s, estimated 9 s

Per ulteriori informazioni sui casi di test, consultate Testing constructs nella AWS Cloud Development Kit (AWS CDK) Developer Guide.

Test di integrazione

I test di integrazione per AWS CDK i costrutti possono essere inclusi anche utilizzando un integ-tests modulo. Un test di integrazione deve essere definito come un' AWS CDK applicazione. Dovrebbe esserci una one-to-one relazione tra un test di integrazione e un' AWS CDK applicazione. Per ulteriori informazioni, visita il integ-tests-alpha modulo nell'AWS CDK API Reference.