Le migliori pratiche per i test - Amazon CodeCatalyst

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 si utilizzano le funzionalità di test fornite da CodeCatalyst, si consiglia di seguire queste best practice.

Rilevamento automatico

Durante la configurazione delle azioni CodeCatalyst, l'individuazione automatica consente di scoprire automaticamente gli output di vari strumenti, come i report dei JUnit test, e di generare CodeCatalyst report pertinenti da essi. L'individuazione automatica aiuta a garantire che i report continuino a essere generati anche se i nomi o i percorsi degli output rilevati 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 nella tua azione, tutti i report dello stesso tipo scoperti automaticamente condivideranno gli stessi criteri di successo. Ad esempio, un criterio condiviso come la frequenza minima di superamento si applicherebbe a tutti i report dei test scoperti automaticamente. Se hai bisogno di criteri diversi per report dello stesso tipo, devi configurare esplicitamente ciascuno di questi report.

  • L'individuazione automatica può anche trovare i report prodotti dalle dipendenze e, se sono configurati criteri di successo, l'azione su questi report potrebbe fallire. Questo problema può essere risolto aggiornando la configurazione del percorso di esclusione.

  • Non è garantito che l'individuazione automatica produca sempre lo stesso elenco di report, 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 smettessero di essere eseguiti 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 successo. Se vuoi che il successo della tua azione dipenda da quel particolare test, devi configurare esplicitamente quel rapporto.

Suggerimento

Quando inizi a lavorare su un progetto nuovo o esistente, usa l'individuazione automatica per l'intera directory del progetto (include**/*). Ciò richiama la generazione di report su tutti i file del progetto, inclusi quelli all'interno delle sottodirectory.

Per ulteriori informazioni, consulta Configurazione dei report sulla qualità in un'azione.

Criteri di successo

È possibile applicare soglie di qualità ai report configurando criteri di successo. Ad esempio, se due report sulla copertura del codice sono stati scoperti automaticamente, 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 di linea all'80%. Ciò comporterebbe l'approvazione del primo rapporto e il fallimento del secondo rapporto, con conseguente fallimento dell'azione complessiva. Per sbloccare il flusso di lavoro, aggiungi nuovi test al progetto fino a quando la copertura di linea per il secondo rapporto non supera l'80%.

  • Imposta i criteri di successo del rilevamento automatico per la copertura di linea al 60%. Ciò comporterebbe l'approvazione di entrambi i report, il che comporterebbe il successo 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 esplicitamente uno o entrambi i report utilizzando l'editor visivo o aggiungendo una YAML sezione e un percorso espliciti per ogni report. Ciò consentirebbe di configurare criteri di successo separati e nomi personalizzati per ogni rapporto. Tuttavia, con questo approccio, l'azione potrebbe fallire se i percorsi dei report cambiano.

Per ulteriori informazioni, consulta Configurazione dei criteri di successo per i report.

Includi/escludi percorsi

Quando si esaminano i risultati delle azioni, è possibile modificare l'elenco dei report generati CodeCatalyst mediante la configurazione e. IncludePaths ExcludePaths

  • Utilizzato IncludePaths per specificare i file e i percorsi dei file CodeCatalyst da includere durante la ricerca di report. Ad esempio, se si specifica"/test/report/*", CodeCatalyst cerca l'intera immagine di build utilizzata dall'azione che cerca la /test/report/ directory. Quando trova quella directory, cerca CodeCatalyst i report in quella directory.

    Nota

    Per i report configurati manualmente, IncludePaths deve essere presente uno schema a globo che corrisponda a un singolo file.

  • ExcludePathsDa utilizzare per specificare i file e i percorsi dei file che si CodeCatalyst desidera escludere durante la ricerca di report. Ad esempio, se si specifica"/test/reports/**/*", non CodeCatalyst cercherà i file nella /test/reports/ directory. Per ignorare tutti i file in una directory, utilizzate il pattern **/* glob.

Di seguito sono riportati alcuni esempi di possibili pattern a glob.

Pattern Descrizione

*.*

Corrisponde a tutti i nomi di 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 chiamatotestFolder, trattandolo come un file

testFolder/*

Corrisponde agli oggetti in un livello della sottocartella datestFolder, ad esempio testFolder/file.xml

testFolder/*/*

Corrisponde agli oggetti in due livelli della sottocartella datestFolder, 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

ExcludePathsha la precedenza su. IncludePaths Se entrambe ExcludePaths includono IncludePaths la stessa cartella, tale cartella non viene analizzata per individuare eventuali report.