Scrivi un test runner Tradefed

Questa pagina descrive come scrivere un nuovo test runner in Tradefed.

Sfondo

Se sei curioso di sapere la posizione dei test runner nell'architettura Tradefed, consulta Struttura di un test runner .

Questo non è un prerequisito per scrivere un nuovo test runner; i test runner possono essere scritti in modo isolato.

Minimo indispensabile: implementare l'interfaccia

Il minimo indispensabile per qualificarsi come test runner Tradefed è implementare l' interfaccia IRemoteTest e più specificamente il metodo run(TestInformation testInfo, ITestInvocationListener listener) .

Questo metodo è quello invocato dal cablaggio quando si utilizza il test runner, simile a Java Runnable.

Ogni parte di tale metodo è considerata parte dell'esecuzione del test runner.

Riportare i risultati dal test runner

Il metodo run nell'interfaccia di base fornisce l'accesso a un oggetto listener di tipo ITestInvocationListener . Questo oggetto è la chiave per riportare i risultati strutturati dal test runner all'imbracatura.

Riportando risultati strutturati, un test runner ha le seguenti proprietà:

• Riporta un elenco corretto di tutti i test eseguiti, quanto tempo hanno impiegato e se hanno superato, fallito individualmente o altri stati.
• Segnalare le metriche associate ai test, se applicabili, ad esempio le metriche relative al tempo di installazione.
• Si adatta alla maggior parte degli strumenti dell'infrastruttura, ad esempio visualizza risultati e metriche, ecc.
• Di solito è più semplice eseguire il debug poiché esiste una traccia più granulare dell'esecuzione.

Detto questo, riportare i risultati strutturati è facoltativo; un test runner potrebbe semplicemente voler valutare lo stato dell'intera corsa come PASSATO o FALLITO senza alcun dettaglio dell'effettiva esecuzione.

È possibile richiamare i seguenti eventi sull'ascoltatore per notificare al cablaggio l'attuale avanzamento delle esecuzioni:

• testRunStarted: notifica l'inizio di un gruppo di casi di test correlati tra loro.
  • testStarted: notifica l'inizio dell'avvio di un test case.
  • testFailed/testIgnored: notifica il cambio di stato del test case in corso. Un test case senza alcun cambiamento di stato è considerato superato.
  • testEnded: notifica la fine del test case.
• testRunFailed: notifica che lo stato generale dell'esecuzione del gruppo di test case è un errore. L' esecuzione di un test può essere un successo o un fallimento indipendentemente dai risultati dei casi di test a seconda di cosa si aspettava l'esecuzione. Ad esempio, un binario che esegue diversi casi di test potrebbe segnalare tutti i casi di test superati ma con un codice di uscita di errore (per qualsiasi motivo: file trapelati, ecc.).
• testRunEnded: notifica la fine del gruppo di casi di test.

Mantenere e garantire l'ordine corretto dei callback è responsabilità dell'implementatore del test runner, ad esempio assicurando che testRunEnded venga chiamato in caso di eccezione utilizzando una clausola finally .

I callback dei casi di test ( testStarted , testEnded , ecc.) sono facoltativi. Un'esecuzione di test potrebbe verificarsi senza casi di test.

Potresti notare che questa struttura di eventi è ispirata alla tipica struttura JUnit . Questo è fatto apposta per mantenere le cose vicine a qualcosa di basilare di cui gli sviluppatori solitamente sono a conoscenza.

Segnala i log dal test runner

Se stai scrivendo la tua classe di test o runner Tradefed, implementerai IRemoteTest e otterrai un ITestInvocationListener tramite il metodo run() . Questo ascoltatore può essere utilizzato per registrare i file come segue:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Prova con un dispositivo

L'interfaccia minima di cui sopra consente di eseguire test molto semplici, isolati e che non richiedono risorse particolari, ad esempio gli unit test Java.

Gli autori di test che desiderano passare alla fase successiva del test del dispositivo avranno bisogno delle seguenti interfacce:

• IDeviceTest permette di ricevere l'oggetto ITestDevice che rappresenta il dispositivo in test e fornisce le API per interagire con esso.
• IBuildReceiver consente al test di ottenere l'oggetto IBuildInfo creato nella fase del provider di build contenente tutte le informazioni e gli artefatti relativi alla configurazione del test.

I test runner sono generalmente interessati a queste interfacce per ottenere artefatti relativi all'esecuzione, ad esempio file aggiuntivi, e ottenere il dispositivo sotto test che verrà preso di mira durante l'esecuzione.

Prova con più dispositivi

Tradefed supporta l'esecuzione di test su più dispositivi contemporaneamente. Ciò è utile quando si testano componenti che richiedono un'interazione esterna, come l'abbinamento di un telefono e un orologio.

Per scrivere un test runner in grado di utilizzare più dispositivi, sarà necessario implementare IMultiDeviceTest , che consentirà di ricevere una mappa di ITestDevice su IBuildInfo che contiene l'elenco completo delle rappresentazioni dei dispositivi e le informazioni di build associate.

Il setter dall'interfaccia verrà sempre chiamato prima del metodo run , quindi è lecito ritenere che la struttura sarà disponibile quando viene chiamato run .

Test consapevoli delle loro configurazioni

Alcune implementazioni dei test runner potrebbero richiedere informazioni sulla configurazione generale per funzionare correttamente, ad esempio alcuni metadati sull'invocazione o quale target_preparer è stato eseguito in precedenza, ecc.

Per raggiungere questo obiettivo, un test runner può accedere all'oggetto IConfiguration di cui fa parte e in cui viene eseguito. Consulta la descrizione dell'oggetto di configurazione per maggiori dettagli.

Per l'implementazione del test runner, sarà necessario implementare IConfigurationReceiver per ricevere l'oggetto IConfiguration .

Corridore di test flessibile

I test runner possono fornire un modo flessibile di eseguire i propri test se hanno un controllo granulare su di essi, ad esempio un test runner JUnit può eseguire individualmente ciascun test unitario.

Ciò consente al cablaggio e all'infrastruttura più grandi di sfruttare quel controllo accurato e agli utenti di eseguire parzialmente il test runner tramite filtraggio .

Il supporto del filtro è descritto nell'interfaccia ITestFilterReceiver , che consente di ricevere set di filtri di include ed exclude per i test che dovrebbero o non dovrebbero essere eseguiti.

La nostra convenzione è che un test verrà eseguito IFF se corrisponde a uno o più filtri di inclusione E non corrisponde a nessuno dei filtri di esclusione. Se non vengono forniti filtri di inclusione, tutti i test dovrebbero essere eseguiti purché non corrispondano a nessuno dei filtri di esclusione.