Test

I test possono essere scritti in modi diversi, ma vengono esposti e invocati in un modo standard definito dalla Standard Test Interface direttamente nel [repository git](https://src.fedoraproject.org/projects/rpms/%2A) del pacchetto. È anche possibile abilitare la pipeline per il namespace dei test, vedi Testing Tests per i dettagli. Per iniziare a lavorare sui test, puoi clonare direttamente il repo di un pacchetto:

Usa fedpkg per clonare il repository git del pacchetto. Vedi la Guida alla Manutenzione dei Pacchetti per maggiori informazioni sullo strumento.

I test vengono abilitati includendo il file tests.yml all’interno della directory tests:

I test sono racchiusi o scritti come playbook Ansible. Ecco un esempio di un semplice playbook che abilita un singolo smoke test per il pacchetto qrencode:

Diamo ora un breve sguardo al playbook per vedere quali variabili sono definite al fine di abilitare lo smoke test:

È possibile suddividere i test in più playbook, ognuno dei quali può rappresentare un test o una parte di un test. Il sistema di testing eseguirà separatamente ciascun playbook che corrisponde al pattern globale tests/tests*.yml in un ambiente pulito. Opzionalmente, è possibile avere più playbook senza il prefisso tests e collegarli dal file tests.yml. Diamo un’occhiata all’esempio di gzip:

Prima di eseguire i test, assicurati di avere le seguenti dipendenze installate sul tuo sistema:

Sebbene alcuni playbook possano funzionare senza sudo, i test vengono sempre invocati come root. Il test stesso può configurare utenti e/o revocare i permessi se fa parte del test. Ma in generale, assicurati di essere root quando invochi i test.

Eseguire un test direttamente sul sistema corrente è semplice:

Per eseguire solo i test adatti ai sistemi classici installati tramite yum o dnf, usa l’argomento --tags:

See Standard Test Roles documentation for detailed instructions how to run tests for a specific Rpm Package, Docker Container or Atomic Host.

Il codice del test stesso può essere memorizzato direttamente nel dist-git (raccomandato come impostazione predefinita) o recuperato da un altro repository ospitato nell’infrastruttura di Fedora, come il [Test Namespace](https://www.google.com/search?q=xref:share-test-code.adoc). Il modo più semplice per aggiungere un nuovo test è utilizzare uno dei " class="xref unresolved">Standard Test Roles(https://www.google.com/search?q=xref:standard-test-roles.adoc) esistenti, che si occupano di molti dettagli di implementazione. Se desideri creare un test personalizzato, segui le istruzioni riportate di seguito.

Una volta identificato un repository dist-git in cui aggiungere i nuovi test (vedi sopra), puoi iniziare a scrivere un nuovo test Ansible. Crea un [playbook Ansible](http://docs.ansible.com/ansible/latest/playbooks.html) con un nuovo nome. Assicurati che l’estensione sia .yml. Inseriamo il seguente esempio nel file test_pid_1.yml.

Tutti i test hanno una directory degli artefatti (artifacts) in cui inseriscono i propri output. Il sistema di testing o di CI che invoca il test valorizzerà questa variabile con una directory che provvederà poi ad archiviare. All’interno del test ci assicuriamo che questa directory esista.

Tramite l’uso dei tags indichiamo su quale tipo di sistemi questo test è adatto a essere eseguito. Quando si includono task aggiuntivi come i pre_tasks, assicurati di impostare anche il tag appropriato. In aggiunta ai tag sopra elencati, è possibile utilizzare anche always per indicare che il task deve essere eseguito in tutti gli ambienti. Per esempio:

La sezione block è quella che esegue il test vero e proprio. In questo esempio, utilizziamo un modo piuttosto articolato per verificare che il PID 1 esista. Tuttavia, così facendo, inseriamo un artefatto di test aggiuntivo nella directory degli artefatti.

Infine, scarichiamo gli artefatti. Ricorda che il test non sempre viene eseguito sullo stesso sistema sul quale è stato invocato. Prova a eseguire questo test di esempio su un [Atomic Host](https://www.google.com/search?q=xref:standard-test-roles.adoc%23_atomic) o su un ">container Docker(https://www.google.com/search?q=xref:standard-test-roles.adoc%23_container). Dovrebbe andare a buon fine. Prova a cambiare l’argomento /proc/1 con un altro valore e il test dovrebbe fallire.

Puoi utilizzare la maggior parte delle tecniche Ansible nei tuoi playbook. Dai un’occhiata a [Standard Test Roles](https://www.google.com/search?q=xref:standard-test-roles.adoc) per trovare i ruoli Ansible che ti semplificheranno la scrittura dei test.

Contrassegnare il test per l’esecuzione

Il solo fatto di avere un file .yml nella directory corretta non significa che verrà invocato. Assicurati di fare riferimento ad esso o di aggiungerlo all’interno di un playbook tests.yml. Questo è il punto di ingresso che il sistema di testing o di CI utilizzerà per invocare tutti i test di un determinato pacchetto.

Se il file tests.yml non esiste ancora, crealo. Continuiamo con il nostro esempio precedente e creiamo un file tests.yml con il seguente contenuto:

Ora puoi eseguire questo test con i comandi standard sopra indicati.

Consulta la Guida rapida per ricevere raccomandazioni su come contribuire con nuovi test.

Diciamo che tu abbia uno script che esegue un test. I suoi stdout e stderr sono l’output del test, e uno stato di uscita pari a zero indica il successo. Ecco come racchiuderemmo quel test per essere invocato. Diciamo di avere uno script semplice come in un file chiamato test-simple

Possiamo scrivere un wrapper Ansible per questo script in questo modo, nel file test_simple.yml:

Tutti i test hanno una directory degli artefatti in cui inseriscono il proprio output. Il sistema di testing o di CI che invoca il test popolerà questa variabile con una directory che provvederà poi ad archiviare. All’interno del test ci assicuriamo che questa directory esista.

Il block è la sezione che esegue il test vero e proprio.

Infine, scarichiamo gli artefatti. Ricorda che il test non sempre viene eseguito sullo stesso sistema sul quale è stato invocato.

Se il file tests.yml non esiste ancora, crealo. Continuiamo con il nostro esempio precedente e creiamo un file tests.yml con il seguente contenuto:

Prova a eseguire questo test di esempio su un Atomic Host o su un Docker Container. Dovrebbe andare a buon fine.

Vedi la documentazione Standard Test Roles per istruzioni su come racchiudere i test BeakerLib e RHTS.

Consulta la Guida rapida per ricevere raccomandazioni su come contribuire con nuovi test.

Se hai bisogno di apportare modifiche al sistema prima del test, includi un task Ansible extra prima della sezione di test. Ad esempio, questo aggiornerà tutti i pacchetti del sistema all’ultima versione: