In questa pagina viene descritto come scrivere un nuovo test runner in Tradefed.
Premessa
Se ti interessa scoprire di più sui test runner nell'architettura Tradefed, consulta la sezione Struttura di un esecutore di test.
Questo non è un prerequisito per la scrittura di un nuovo test runner; i test runner possono essere scritte in modo isolato.
Minimo indispensabile: implementa l'interfaccia
Il minimo indispensabile per qualificarsi come runner del test Tradefed è implementare le
Interfaccia IRemoteTest
e in particolare il metodo run(TestInformation testInfo, ITestInvocationListener listener)
.
Questo metodo è quello richiamato dal cablaggio quando si utilizza il test runner, in modo simile a Java Runnable.
Ogni parte di questo metodo è considerata parte dell'esecuzione del test runner.
Segnala i risultati dall'esecutore del test
Il metodo run
nell'interfaccia di base consente di accedere a un oggetto listener di
digita ITestInvocationListener
. Questo è l'elemento chiave per la creazione di report strutturati
i risultati dal test runner all'imbracatura.
Generando report sui risultati strutturati, un runner del test ha le seguenti proprietà:
- Segnalare un elenco corretto di tutti i test eseguiti, della durata e dell'eventuale vengono superati singolarmente, non sono riusciti o presentano altri stati.
- Segnala le metriche associate ai test, se applicabili, ad esempio e metriche relative al tempo di installazione.
- Si adatta alla maggior parte degli strumenti dell'infrastruttura, ad esempio risultati di visualizzazione e metriche ecc.
- Di solito è più facile eseguire il debug poiché esiste una traccia più granulare dell'esecuzione.
Detto questo, la generazione di report sui risultati strutturati è facoltativa. un runner di prova potrebbe se vuoi semplicemente valutare lo stato dell'intera esecuzione come SUPERATA o NON RIUSCITA senza dettagli dell'esecuzione effettiva.
I seguenti eventi possono essere chiamati sul listener per notificare il cablaggio del avanzamento attuale delle esecuzioni:
- testRunStarted: invia una notifica all'inizio di un gruppo di scenari di test che sono
correlate tra loro.
- testStarted: invia una notifica all'inizio di uno scenario di test in corso.
- testFailed/testIgnorad: invia una notifica alla modifica di stato dello scenario di test in corso. Viene preso in considerazione uno scenario di test senza alcuna modifica di stato superato.
- testEnded: invia una notifica alla fine dello scenario di test.
- testRunFailed: segnala che lo stato generale del gruppo di scenari di test l'esecuzione è un errore. Un test può essere superato o fail indipendentemente dai risultati degli scenari di test, a seconda di cosa prevista l'esecuzione. Ad esempio, un file binario che esegue diversi scenari di test potresti segnalare tutti gli scenari di test Superamento ma con un codice di uscita di errore (per qualsiasi motivi: file divulgati ecc.).
- testRunEnded: invia una notifica alla fine del gruppo di scenari di test.
Mantenere e garantire l'ordine corretto dei callback
responsabilità dell'implementatore dell'esecutore dei test, ad esempio garantire
testRunEnded
viene chiamato in caso di eccezione utilizzando una clausola finally
.
I callback degli scenari di test (testStarted
, testEnded
e così via) sono facoltativi. Un test
dell'esecuzione potrebbe avvenire senza scenari di test.
Come puoi notare, questa struttura di eventi si ispira della tipica struttura di JUnit. Lo scopo è quello di avvicinarsi a elementi basilari che gli sviluppatori di cui sono a conoscenza.
Log dei report dell'esecutore del test
Se stai scrivendo la tua classe di test o runner Tradefed, implementerai
Testa remota
e ottieni un ITestInvocationListener
tramite il metodo run()
. Questo listener
può essere utilizzato per registrare i file nel seguente modo:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Esegui il test con un dispositivo
L'interfaccia minima indicata sopra consente di eseguire test molto semplici che vengono isolati e non richiedono risorse particolari, ad esempio i test delle unità Java.
Gli autori di test che vogliono andare al passaggio successivo del test del dispositivo dovranno avere le seguenti interfacce:
- Test dispositivo
consente di ricevere l'oggetto
ITestDevice
che rappresenta il dispositivo il test e fornisce l'API per interagire. - IBuildReceiver
consente al test di ottenere l'oggetto
IBuildInfo
creato passaggio del provider di creazione contenente tutte le informazioni e gli artefatti relativi alla configurazione del test.
I test runner sono generalmente interessati a queste interfacce per ottenere gli artefatti relativi all'esecuzione, ad esempio file aggiuntivi, e dispositivo sottoposto a test che verrà scelto come target durante l'esecuzione.
Eseguire test su più dispositivi
Tradefed supporta l'esecuzione di test su più dispositivi contemporaneamente. Questo è è 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, è necessario
per implementare
IMultiDeviceTest,
che consentirà di ricevere una mappa da ITestDevice
a IBuildInfo
che contiene
l'elenco completo delle rappresentazioni dei dispositivi e le relative informazioni di build.
Il setter dell'interfaccia verrà sempre chiamato prima del metodo run
, quindi
si può presumere che la struttura sarà disponibile quando verrà chiamato run
.
Test della loro configurazione
Alcune implementazioni dell'esecutore di test potrebbero richiedere informazioni sulla configurazione complessiva
per funzionare correttamente, ad esempio alcuni metadati sulla chiamata oppure
che target_preparer
è stata eseguita in precedenza e così via.
A questo scopo, un runner del test può accedere all'oggetto IConfiguration
di cui fa parte e in cui viene eseguita. Consulta le
oggetto di configurazione
Descrizione per ulteriori dettagli.
Per l'implementazione dell'esecutore del test, dovrai implementare il metodo
IConfigurationReceiver
per ricevere l'oggetto IConfiguration
.
Esecutore di test flessibile
Gli esecutori dei test possono fornire un modo flessibile per eseguire i test se dispongono di una un controllo granulare su di essi, ad esempio un runner dei test JUnit può eseguire il test di ogni unità.
Ciò consente all'infrastruttura e all'infrastruttura più ampia di sfruttare il controllo e agli utenti di eseguire parzialmente il runner del test tramite filtri.
Il supporto dei filtri è descritto nella sezione
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 corrisponde a uno o più dei includi filtri E non corrisponde a nessuno dei filtri di esclusione. In caso contrario, includi filtri, tutti i test devono essere eseguiti a patto che non corrispondano i filtri di esclusione.