Scrivi un test Runner Tradefed

Questa pagina descrive come scrivere un nuovo test runner in Tradefed.

Sfondo

Se siete curiosi di sapere il luogo di corridori prova nell'architettura Tradefed, vedere Struttura di un test runner .

Questo non è un prerequisito per scrivere un nuovo test runner; i test runner possono essere scritti isolatamente.

Il minimo indispensabile: implementazione dell'interfaccia

Il minimo indispensabile per qualificarsi come test corridore Tradefed è attuare l'interfaccia IRemoteTest e più specificamente la run(TestInformation testInfo, ITestInvocationListener listener) metodo.

Questo metodo è quello invocato dall'imbracatura quando si utilizza il test runner, simile a un Java Runnable.

Ogni parte di quel metodo è considerata parte dell'esecuzione del test runner.

Riportare i risultati dal test runner

La run metodo nell'interfaccia di base accesso give a un oggetto ascoltatore 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, per quanto tempo hanno impiegato e se individualmente hanno superato, fallito o altri stati.
  • Se applicabile, riporta le metriche associate ai test, ad esempio le metriche del tempo di installazione.
  • Adatta alla maggior parte degli strumenti dell'infrastruttura, ad esempio visualizza risultati e metriche, ecc.
  • Di solito è più facile eseguire il debug poiché esiste una traccia più granulare dell'esecuzione.

Detto questo, la segnalazione dei risultati strutturati è facoltativa; un test runner potrebbe semplicemente voler valutare lo stato dell'intera corsa come SUPERATO o NON RIUSCITO senza alcun dettaglio dell'esecuzione effettiva.

NOTA: è più difficile implementare un corridore che segua la sequenza degli eventi, ma consigliamo di farlo visti i vantaggi sopra elencati.

I seguenti eventi possono essere chiamati sul listener per notificare al cablaggio l'avanzamento corrente delle esecuzioni:

  • testRunStarted: notifica l'inizio di un gruppo di casi di test correlati tra loro.
    • testStarted: notifica l'inizio di un test case.
    • testFailed/testIgnored: notifica il cambiamento 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 casi di test è un errore. Un test può essere un passaggio o un sicuro indipendentemente dai casi di test risultati a seconda di ciò l'esecuzione si aspettava. Ad esempio, un binario in esecuzione diversi casi di test potrebbe segnalare tutti i casi di test passaggio ma con un codice di uscita di errore (per qualsiasi motivo: file trapelato, ecc).
  • testRunEnded: notifica la fine del gruppo di casi di test.

Mantenere e garantire il corretto ordine dei callback è responsabilità del test corridore realizzatore, per esempio assicurando che testRunEnded viene richiamato in caso di eccezione utilizzando un finally clausola.

Casi di test callback ( testStarted , testEnded , etc.) sono opzionali. Potrebbe verificarsi un'esecuzione di test senza casi di test.

Si potrebbe notare che questa struttura di eventi è ispirata dalla tipica struttura JUnit . Questo è allo scopo di mantenere le cose vicine a qualcosa di base di cui gli sviluppatori di solito hanno conoscenza.

Reporting log dal test runner

Se si sta scrivendo la propria classe di prova Tradefed o un corridore, si implementare IRemoteTest e ottenere un ITestInvocationListener attraverso il run() metodo. Questo listener può essere utilizzato per registrare i file come segue:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Test con un dispositivo

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

Scrittori di prova che vogliono andare alla fase successiva del test del dispositivo sono necessari i seguenti interfacce:

  • IDeviceTest permette di ricevere l' ITestDevice oggetto che rappresenta il dispositivo in prova e fornisce l'API per interagire con esso.
  • IBuildReceiver permette il test per ottenere IBuildInfo oggetto creato al passo fornitore di accumulo contenente tutte le informazioni e gli artefatti legati alla configurazione di prova.

I test runner sono solitamente interessati a queste interfacce per ottenere artefatti relativi all'esecuzione, ad esempio file extra, e ottenere il dispositivo in prova che verrà preso di mira durante l'esecuzione.

Test 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 un telefono e l'associazione di un orologio.

Per scrivere un corridore test in grado di utilizzare più dispositivi, è necessario implementare l'IMultiDeviceTest , che permetterà di ricevere una mappa di ITestDevice a IBuildInfo che contiene l'elenco completo delle rappresentazioni dei dispositivi e le loro informazioni di build associato.

Il setter dall'interfaccia sarà sempre chiamato prima della run metodo, quindi è lecito ritenere che la struttura sarà disponibile quando run viene chiamato.

I test sono consapevoli delle loro configurazioni

NOTA: questo non è un caso d'uso molto comune. È documentato per completezza, ma di solito non ne avrai bisogno.

Alcune implementazioni di prova corridore potrebbero avere bisogno di informazioni sulla configurazione globale, al fine di funzionare correttamente, ad esempio alcuni metadati relativi l'invocazione, o che target_preparer corse innanzi, etc.

Per conseguire questo, un corridore test può accedere IConfiguration oggetto è parte e che è eseguito nel. Vedi l' oggetto di configurazione descrizione per ulteriori dettagli.

Per l'attuazione di prova corridore, è necessario implementare l'IConfigurationReceiver per ricevere IConfiguration oggetto.

Corridore di prova flessibile

I test runner possono fornire un modo flessibile di eseguire i loro test se hanno un controllo granulare su di essi, ad esempio un test runner JUnit può eseguire individualmente ogni unit test.

Questo permette al cablaggio più grande e infrastrutture di leva che controllo fine e utenti di eseguire parzialmente il test runner tramite filtrazione.

Supporto filtrante è descritta nella interfaccia ITestFilterReceiver , che consente di ricevere insiemi di include ed exclude filtri per i test che dovrebbe o non dovrebbe eseguire.

La nostra convenzione è che un test verrà eseguito IFF 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 devono essere eseguiti purché non corrispondano a nessuno dei filtri di esclusione.

NOTA: Incoraggiamo i test runner a scrivere in un modo che supporti questo filtro in quanto fornisce un enorme valore aggiunto nell'infrastruttura più ampia. Ma capiamo che in alcuni casi non è possibile farlo.