Amazon non CodeCatalyst è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md).
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à.
# Le migliori pratiche per i test
Quando utilizzi le funzionalità di test fornite da CodeCatalyst, ti consigliamo di seguire queste best practice.
**Topics**
+ [Auto-discovery](#test.best-auto-discovery)
+ [Criteri di successo](#test.best-success-criteria)
+ [Include/exclude percorsi](#test.best-include-exclude)
## Auto-discovery
Quando si configurano le azioni in CodeCatalyst, l'individuazione automatica consente di scoprire automaticamente gli output di vari strumenti, come i report di test di JUnit, e di generare report pertinenti CodeCatalyst da essi. Auto-discovery aiuta a garantire che i report continuino a essere generati anche se i nomi o i percorsi degli output scoperti cambiano. Quando vengono aggiunti nuovi file, li CodeCatalyst rileva automaticamente e produce report pertinenti. Tuttavia, se si utilizza l'individuazione automatica, è importante tenere conto di alcuni dei seguenti aspetti di questa funzionalità:
+ Quando attivi l'individuazione automatica in Action, tutti i report dello stesso tipo scoperti automaticamente condivideranno gli stessi criteri di successo. Ad esempio, un criterio condiviso, come la percentuale minima di superamento, si applicherebbe a tutti i report di test rilevati automaticamente. Se sono necessari criteri diversi per i report dello stesso tipo, è necessario configurare esplicitamente ciascuno di questi report.
+ Auto-discovery puoi anche trovare i report prodotti dalle tue dipendenze e, se i criteri di successo sono configurati, potrebbe fallire l'azione su questi report. Questo problema può essere risolto aggiornando la configurazione del percorso di esclusione.
+ Auto-discovery non è garantito che produca lo stesso elenco di report ogni volta, poiché analizza l'azione in fase di esecuzione. Nel caso in cui si desideri che venga sempre prodotto un determinato report, è necessario configurare i report in modo esplicito. Ad esempio, se i test dovessero interrompere l'esecuzione come parte della build, il framework di test non produrrebbe alcun output e, di conseguenza, non verrebbe prodotto alcun rapporto di test e l'azione potrebbe avere esito positivo. Se vuoi che il successo della tua azione dipenda da quel particolare test, devi configurare esplicitamente quel report.
**Suggerimento**
Quando inizi un progetto nuovo o esistente, utilizza l'individuazione automatica per l'intera directory del progetto (include`**/*`). Ciò richiama la generazione di report per tutti i file del progetto, inclusi quelli all'interno delle sottodirectory.
Per ulteriori informazioni, consulta [Configurazione dei report sulla qualità in un'azione](test-config-action.md).
## Criteri di successo
Puoi applicare soglie di qualità nei tuoi report configurando i criteri di successo. Ad esempio, se vengono rilevati automaticamente due report sulla copertura del codice, uno con una copertura di linea dell'80% e l'altro con una copertura di linea del 60%, sono disponibili le seguenti opzioni:
+ Imposta i criteri di successo del rilevamento automatico per la copertura della linea all'80%. Ciò comporterebbe l'approvazione del primo report e l'esito negativo del secondo, con conseguente fallimento dell'azione complessiva. Per sbloccare il flusso di lavoro, aggiungete nuovi test al progetto fino a quando la copertura della linea per il secondo report non superi l'80%.
+ Imposta i criteri di successo del rilevamento automatico per la copertura della linea al 60%. Ciò comporterebbe il superamento di entrambi i report, con conseguente esito positivo dell'azione. Potresti quindi lavorare per aumentare la copertura del codice nel secondo rapporto. Tuttavia, con questo approccio, non è possibile garantire che la copertura del primo rapporto non scenda al di sotto dell'80%.
+ Configura in modo esplicito uno o entrambi i report utilizzando l'editor visuale o aggiungendo una sezione e un percorso YAML espliciti per ogni report. Ciò consentirebbe di configurare criteri di successo separati e nomi personalizzati per ogni report. Tuttavia, con questo approccio, l'azione potrebbe fallire se i percorsi del report cambiano.
Per ulteriori informazioni, consulta [Configurazione dei criteri di successo per i report](test-config-action.md#test.success-criteria).
## Include/exclude percorsi
Quando si esaminano i risultati delle azioni, è possibile modificare l'elenco dei report generati CodeCatalyst da configurando `IncludePaths` e`ExcludePaths`.
+ `IncludePaths`Utilizzalo per specificare i file e i percorsi dei file CodeCatalyst da includere durante la ricerca dei report. Ad esempio, se specifichi`"/test/report/*"`, CodeCatalyst esegue la ricerca nell'intera immagine di build utilizzata dall'azione cercando la `/test/report/` directory. Quando trova quella directory CodeCatalyst , cerca i report in quella directory.
**Nota**
Per i report configurati manualmente, `IncludePaths` deve essere un modello globale che corrisponda a un singolo file.
+ Consente `ExcludePaths` di specificare i file e i percorsi dei file CodeCatalyst da escludere durante la ricerca dei report. Ad esempio, se lo specifichi`"/test/reports/**/*"`, non CodeCatalyst cercherà i file nella `/test/reports/` directory. Per ignorare tutti i file in una directory, usa il pattern `**/*` glob.
Di seguito sono riportati alcuni esempi di possibili pattern glob.
| Pattern | Description |
| --- | --- |
| `*.*` | Corrisponde a tutti i nomi degli oggetti nella directory corrente che contengono un punto |
| `*.xml` | Corrisponde a tutti i nomi degli oggetti nella directory corrente che terminano con `.xml` |
| `*.{xml,txt}` | Corrisponde a tutti i nomi degli oggetti nella directory corrente che terminano con `.xml` o `.txt` |
| `**/*.xml` | Corrisponde ai nomi degli oggetti in tutte le directory che terminano con `.xml` |
| `testFolder` | Corrisponde a un oggetto chiamato`testFolder`, trattandolo come un file |
| `testFolder/*` | Corrisponde agli oggetti contenuti in un livello della sottocartella da`testFolder`, ad esempio `testFolder/file.xml` |
| `testFolder/*/*` | Corrisponde agli oggetti in due livelli della sottocartella da`testFolder`, ad esempio `testFolder/reportsFolder/file.xml` |
| `testFolder/**` | Individua la sottocartella `testFolder`, insieme ai file all'interno di `testFolder`, ad esempio `testFolder/file.xml` e `testFolder/otherFolder/file.xml` |
CodeCatalyst interpreta i pattern globulari come segue:
+ Il carattere slash (`/`) separa le directory nei percorsi dei file.
+ L'asterisco (`*`) individua zero o più caratteri di un componente del nome entro i limiti della cartella.
+ Un doppio asterisco (`**`) corrisponde a zero o più caratteri di un componente del nome in tutte le directory.
**Nota**
`ExcludePaths`ha la precedenza su. `IncludePaths` Se entrambi `ExcludePaths` includono `IncludePaths` la stessa cartella, tale cartella non viene analizzata alla ricerca di report.