Google Espresso o Robotium [chiuso]

Devo usare lo strumento di test automatizzato dell'interfaccia utente e sono confuso tra l'utilizzo di Robotium e Google Espresso.

Quali sono le principali differenze tra i due? Ci sono caratteristiche che esistono in uno ma non nell'altro?

Divulgazione completa: sono uno degli autori di Espresso.

Sia Espresso che Robotium sono framework basati sulla strumentazione, il che significa che utilizzano Android Instrumentation per ispezionare e interagire con le attività sotto test.

In Google, abbiamo iniziato utilizzando Robotium perché era più conveniente della strumentazione di serie (tanto di cappello agli sviluppatori Robotium per averlo reso così). Tuttavia, non ha soddisfatto la nostra esigenza di un framework che rendesse facile la scrittura di test affidabili per gli sviluppatori.

I principali progressi di Espresso rispetto a Robotium:

1. Sincronizzazione. Per impostazione predefinita, la logica del test di strumentazione viene eseguita su un thread (strumentazione) diverso rispetto alle operazioni dell'interfaccia utente (elaborate sul thread dell'interfaccia utente). Senza la sincronizzazione delle operazioni di test con gli aggiornamenti dell'interfaccia utente, i test saranno soggetti a instabilità, ovvero falliranno casualmente a causa di problemi di temporizzazione. La maggior parte degli autori di test ignora questo fatto, alcuni aggiungono meccanismi di sospensione / ripetizione e ancora meno implementano un codice di thread safety più sofisticato. Nessuno di questi è l'ideale. Espresso si prende cura della sicurezza dei thread sincronizzando perfettamente le azioni e le asserzioni di test con l'interfaccia utente dell'applicazione sottoposta a test. Robotium tenta di risolvere questo problema con meccanismi di sospensione / ripetizione, che non solo sono inaffidabili, ma fanno anche sì che i test vengano eseguiti più lentamente del necessario.

2. API. Espresso ha un'API piccola, ben definita e prevedibile, aperta alla personalizzazione. Si dice al framework come individuare un elemento dell'interfaccia utente utilizzando gli abbinamenti hamcrest standard e quindi gli si chiede di eseguire un'azione o di controllare un'asserzione sull'elemento di destinazione. Puoi contrastarlo con l'API di Robotium, in cui l'autore del test dovrebbe scegliere tra oltre 30 metodi di clic. Inoltre, Robotium espone metodi pericolosi come getCurrentActivity (cosa significa comunque current?) E getView, che consentono di operare su oggetti al di fuori del thread principale (vedere il punto sopra).

3. Informazioni chiare sull'errore. Espresso si impegna a fornire ricche informazioni di debug quando si verifica un errore. Inoltre, puoi personalizzare il modo in cui i guasti vengono gestiti da Espresso con il tuo gestore dei guasti. Non l'ho provato per un po ', ma le versioni precedenti di Robotium soffrivano di una gestione degli errori incoerente (ad esempio, il metodo clickOnView avrebbe ingoiato SecurityExceptions).

Contrariamente a una risposta precedente, Espresso è supportato su tutte le versioni API con un numero significativo di utenti (vedi: http://developer.android.com/about/dashboards/index.html ). Funziona su alcune delle versioni precedenti, ma testarle sarebbe uno spreco di risorse. A proposito di test ... Espresso viene testato su ogni modifica da una suite di test completa (con oltre il 95% di copertura) e dalla maggior parte delle applicazioni Android sviluppate da Google.

Espresso è molto più veloce di Robotium, ma funziona solo su alcune versioni di SDK.

Quindi, se vuoi un test che funzioni su tutti i dispositivi, scegli Roboitum. In caso contrario, scegli un espresso e non dimenticare che sarai un beta tester per ancora un po 'di tempo.