Il ciclo di vita di un test eseguito utilizzando Trade Federation è composto da quattro fasi separate, progettate attorno a interfacce definite formalmente.
Interfacce definite
- Provider di build : fornisce una build da testare, scaricando i file appropriati se necessario.
- Preparatore di destinazione : prepara l'ambiente di test, includendo eventualmente l'installazione del software e la configurazione del dispositivo.
- Test : esegue i test e raccoglie i risultati dei test. Potrebbe trattarsi di qualsiasi JUnit Test, sebbene la nostra interfaccia IRemoteTest sia specificamente progettata per funzionare bene nell'ambiente della Trade Federation.
- Test Invocation Listener (report dei risultati) : ascolta i risultati del test, di solito allo scopo di inoltrare i risultati del test a un repository o mostrarli al Test Runner.
L'entità di test fondamentale in TF è una configurazione (config). Una configurazione è un file XML che dichiara i componenti del ciclo di vita di un test.
Questa separazione del ciclo di vita del test ha lo scopo di consentire il riutilizzo. Utilizzando questo design, lo sviluppatore può creare un test una volta, quindi l'integratore può creare configurazioni diverse per eseguire quel test in ambienti diversi. Ad esempio, potrebbero creare una configurazione che eseguirà un test su una macchina locale e scaricherà il risultato su stdout. Potrebbero quindi creare una seconda configurazione in grado di eseguire lo stesso test, ma utilizzare un listener di chiamate di test diverso per archiviare i risultati del test in un database. Una terza configurazione potrebbe essere progettata per eseguire quel test continuamente da un laboratorio di test da qualche parte.
È conveniente notare qui che una configurazione insieme ai suoi argomenti della riga di comando (come forniti da Test Runner) è nota come Command . Quando TF accoppia un Command con un ITestDevice e lo esegue, l'oggetto successivo è noto come Invocation . In breve, un'invocazione comprende un'esecuzione di test TF completa, durante l'intero ciclo di vita.
Componenti di configurazione aggiuntivi
- Recupero dispositivo : meccanismo per ripristinare la comunicazione del dispositivo in caso di smarrimento.
- Logger : raccoglie i dati di registrazione scambiati.
Stage output ed errori
Ogni fase di un'invocazione viene eseguita in sequenza e ha un obiettivo specifico. Questa sezione descrive le uscite e gli errori usuali di ciascuna fase.
Costruisci fornitore
Questa fase crea e restituisce un oggetto IBuildInfo che contiene tutti i riferimenti ai file necessari per impostare ed eseguire i test.
L'errore più comune in questa fase è l'impossibilità di scaricare o trovare i file richiesti.
Un errore in questa fase comporta la segnalazione diretta dell'errore e l'esecuzione di nessun test.
Preparazione del bersaglio
Questa fase stabilisce gli stati necessari per l'obiettivo sottoposto a test. Questa fase può modificare la configurazione del dispositivo o dell'host in base alle esigenze per la chiamata al test specificata.
Gli errori comuni in questa fase di solito comportano la mancata configurazione del dispositivo in un determinato stato (ad esempio, flashing non riuscito) e la mancata ricerca dei file richiesti per l'installazione.
Un errore in questa fase comporta l'esecuzione della pulizia della destinazione, la segnalazione dell'errore e l'assenza di test in esecuzione.
Prove
Questa fase esegue i test richiesti sul target precedentemente preparato e riporta tutti i risultati dell'esecuzione del test.
Gli errori comuni in questa fase di solito implicano la non disponibilità del target sottoposto a test o qualche errore che causa l'esecuzione parziale dei test. Questi errori sono problemi di infrastruttura che influiscono sull'esecuzione del test stesso anziché sull'errore di un singolo test case.
Un errore in questa fase comporta l'arresto dell'esecuzione del test, la pulizia del target in esecuzione, la segnalazione dell'errore e l'ottenimento di risultati parziali.
Segnalazione dei risultati
Questa fase riporta i risultati e gli errori ai servizi configurati (ad esempio server e file locali).
Sebbene i singoli reporter dei risultati possano avere errori, sono isolati l'uno dall'altro (un reporter non vede errori da un altro). Questi errori influiscono solo sulla segnalazione dei risultati di un singolo segnalatore e gli errori possono essere visualizzati nei registri.