Scrivi un runner di prova Tradefed

In questa pagina viene descritto come scrivere un nuovo test runner in Tradefed.

Background

Se vuoi saperne di più sul ruolo dei test runner nell'architettura di TradeFed, consulta la sezione Struttura di un test runner.

Non è un prerequisito per scrivere un nuovo programma di test; i programmi di test possono essere scritti in modo indipendente.

Minimo indispensabile: implementa l'interfaccia

Il minimo indispensabile per diventare runner del test Tradefed è implementare l'interfaccia IRemoteTest e, più nello specifico, il metodo run(TestInformation testInfo, ITestInvocationListener listener).

Questo metodo è quello invocato dall'harness quando si utilizza il programma di test, simile a un Runnable Java.

Ogni parte di questo metodo è considerata parte dell'esecuzione del programma di test.

Report sui risultati del programma di test

Il metodo run nell'interfaccia di base consente di accedere a un oggetto listener di tipo ITestInvocationListener. Questo oggetto è la chiave per generare report su risultati strutturati dal programma di test all'harness.

Se genera risultati strutturati, un programma di test ha le seguenti proprietà:

• Segnalare un elenco corretto di tutti i test eseguiti, della durata della sessione e di se sono stati superati singolarmente, non sono stati superati o sono stati eseguiti in altri stati.
• Report sulle metriche associate ai test, se applicabili, ad esempio le metriche relative al momento dell'installazione.
• Adattarsi alla maggior parte degli strumenti di infrastruttura, ad esempio visualizzare risultati e metriche e così via.
• Di solito è più facile eseguire il debug perché esiste una traccia più granulare dell'esecuzione.

Detto questo, la generazione di report sui risultati strutturati è facoltativa. Un utente che esegue il test potrebbe semplicemente valutare lo stato dell'intera esecuzione come PASSATO o NON SUPERATO senza dettagli sull'esecuzione effettiva.

I seguenti eventi possono essere chiamati nell'ascoltatore per notificare all'harness l'avanzamento corrente delle esecuzioni:

• testRunStarted: notifica l'inizio di un gruppo di casi di test correlati tra loro.
  • testStarted: invia una notifica all'inizio di uno scenario di test in corso.
  • testFailed/testIgnorad: comunica la modifica di stato dello scenario di test in corso. Un caso di test senza alcuna modifica dello stato è considerato superato.
  • testEnded: notifica la fine del test case.
• testRunFailed: notifica che lo stato generale dell'esecuzione del gruppo di casi di test è un errore. Un'esecuzione di test può essere successiva o fail indipendentemente dai risultati degli scenari di test, a seconda di ciò che l'esecuzione si aspettava. Ad esempio, un file binario che esegue diversi casi di test potrebbe segnalare tutti i casi di test passati, ma con un codice di uscita di errore (per qualsiasi motivo: file con dati trapelati e così via).
• testRunEnded: notifica la fine del gruppo di casi di test.

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

I callback dei casi di test (testStarted, testEnded e così via) sono facoltativi. Un test potrebbe avvenire senza scenari di test.

Potresti notare che questa struttura di eventi è ispirata alla struttura JUnit tipica. Lo scopo è quello di avvicinarsi a elementi basilari di cui gli sviluppatori di solito sono a conoscenza.

Generare log dal programma di esecuzione dei test

Se stai scrivendo la tua classe o il tuo runner di test 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);

Eseguire il test con un dispositivo

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

Gli autori di test che vogliono passare al passaggio successivo del test del dispositivo avranno bisogno delle seguenti interfacce:

• IDeviceTest consente di ricevere l'oggetto ITestDevice che rappresenta il dispositivo in esame e fornisce l'API per interagire con esso.
• IBuildReceiver consente al test di recuperare l'oggetto IBuildInfo creato nel passaggio del provider di compilazione contenente tutte le informazioni e gli elementi correlati alla configurazione del test.

I programmatori di test sono in genere interessati a queste interfacce per ottenere elementi correlati all'esecuzione, ad esempio file aggiuntivi, e per ottenere il dispositivo di test che verrà scelto come target durante l'esecuzione.

Esegui test con più dispositivi

Tradefed supporta l'esecuzione di test su più dispositivi contemporaneamente. Questa funzionalità è utile per testare componenti che richiedono un'interazione esterna, ad esempio l'accoppiamento di uno smartphone e uno smartwatch.

Per scrivere un test runner che possa utilizzare più dispositivi, dovrai implementare IMultiDeviceTest, che ti consentirà di ricevere una mappa da ITestDevice a IBuildInfo contenente l'elenco completo delle rappresentazioni dei dispositivi e le relative informazioni di build associate.

Il metodo setter dell'interfaccia verrà sempre chiamato prima del metodo run, quindi è possibile presumere che la struttura sarà disponibile quando viene chiamato run.

Test della loro configurazione

Alcune implementazioni del programma di test potrebbero richiedere informazioni sulla configurazione complessiva per funzionare correttamente, ad esempio alcuni metadati sull'invocazione o su quale target_preparer è stato eseguito in precedenza e così via.

Per farlo, un programma di esecuzione dei test può accedere all'oggetto IConfiguration di cui fa parte e in cui viene eseguito. Per ulteriori dettagli, consulta la descrizione dell'oggetto di configurazione.

Per l'implementazione del test runner, devi implementare IConfigurationReceiver per ricevere l'oggetto IConfiguration.

Esecutore di test flessibile

I runner dei test possono fornire un modo flessibile per eseguire i test se dispongono di un controllo granulare su di essi. Ad esempio, un runner dei test JUnit può eseguire singolarmente ogni test unitario.

In questo modo, l'infrastruttura e il traino più grandi possono sfruttare questo controllo granulare e gli utenti possono eseguire parzialmente il programma di test tramite il filtro.

Il supporto dei filtri è descritto nell'interfaccia ITestFilterReceiver, che consente di ricevere insiemi di filtri include e exclude per i test che devono o non devono essere eseguiti.

La nostra convenzione prevede che un test venga eseguito se soddisfa uno o più filtri di inclusione E non corrisponde a nessuno dei filtri di esclusione. Se non vengono specificati filtri di inclusione, tutti i test devono essere eseguiti a condizione che non corrispondano a nessuno dei filtri di esclusione.