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.