Scrivi un programma di test Tradefed

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

Premessa

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 poter essere considerato un programma di test Tradefed è implementare l'interfaccia IRemoteTest e, più specificamente, 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.

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 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 e dell'eventuale vengono superati singolarmente, non sono riusciti o presentano altri stati.
  • Report sulle metriche associate ai test, se applicabili, ad esempio le metriche relative al momento dell'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 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 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/testIgnored: notifica la modifica dello stato del caso 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 superata o non riuscita. 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'esecuzione del test 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.

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 listener può essere utilizzato per registrare i file nel seguente modo:

    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 andare al passaggio successivo del test del dispositivo dovranno avere le 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 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 a conoscenza delle proprie configurazioni

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.

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 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.

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 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 è che un test venga eseguito se e solo se corrisponde a uno o più dei filtri di inclusione 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.