Scrivi un runner di prova Tradefed

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.