

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
<a name="development-best-practices"></a>

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 CDK[assertions](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html) e i framework di test più diffusi, come [Jest](https://jestjs.io/) for e/o pytest for TypeScript JavaScript Python.](https://docs.pytest.org/en/6.2.x/)

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
<a name="unit-test"></a>

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/jest``jest`, e `ts-jest` in`devDependencies`. 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à\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/images/unit_test_structure.png)


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](https://docs.aws.amazon.com/cdk/v2/guide/testing.html) nella *AWS Cloud Development Kit (AWS CDK) Developer* Guide.

## Test di integrazione
<a name="integration-test"></a>

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](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) nell'*AWS CDK API Reference*.