Google Espresso ou Robotium [fechado]

Eu tenho que usar a ferramenta de teste de IU automatizada e estou confuso entre usar Robotium e Google Espresso.

Quais são as principais diferenças entre os dois? Existem recursos em um, mas não no outro?

Divulgação total: Sou um dos autores do Espresso.

Tanto o Espresso quanto o Robotium são estruturas baseadas em instrumentação, o que significa que usam a Instrumentação Android para inspecionar e interagir com as atividades em teste.

No Google, começamos usando o Robotium porque era mais conveniente do que a instrumentação de estoque (tiro o chapéu aos desenvolvedores do Robotium por fazer isso). No entanto, isso não satisfez nossa necessidade de uma estrutura que tornasse a escrita de testes confiáveis fácil para os desenvolvedores.

Os principais avanços do Espresso em relação ao Robotium:

1. Sincronização. Por padrão, a lógica de teste de instrumentação é executada em um encadeamento (instrumentação) diferente das operações de IU (processadas no encadeamento de IU). Sem a sincronização das operações de teste com as atualizações da IU, os testes ficarão sujeitos a falhas - ou seja, falharão aleatoriamente devido a problemas de tempo. A maioria dos autores de teste ignora esse fato, alguns adicionam mecanismos de suspensão / repetição e menos ainda implementam um código de segurança de thread mais sofisticado. Nenhum deles é ideal. O Espresso cuida da segurança do thread, sincronizando perfeitamente as ações e asserções de teste com a IU do aplicativo em teste. Robotium tenta resolver isso com mecanismos de suspensão / nova tentativa, que não são apenas não confiáveis, mas também fazem com que os testes sejam executados mais lentamente do que o necessário.

2. API. O Espresso possui uma API pequena, bem definida e previsível, que pode ser customizada. Você diz ao framework como localizar um elemento de IU usando matchers hamcrest padrão e, em seguida, instrui-o a executar uma ação ou verificar uma asserção no elemento de destino. Você pode comparar isso com a API do Robotium, onde o autor do teste deve escolher entre mais de 30 métodos de clique. Além disso, Robotium expõe métodos perigosos como getCurrentActivity (o que significa current, afinal?) E getView, que permitem operar em objetos fora do thread principal (consulte o ponto acima).

3. Informações claras sobre a falha. O Espresso se esforça para fornecer informações valiosas de depuração quando ocorre uma falha. Além disso, você pode personalizar a maneira como as falhas são tratadas pelo Espresso com seu próprio gerenciador de falhas. Eu não tentei fazer isso por um tempo, mas as versões anteriores do Robotium sofriam de falha inconsistente no manuseio (por exemplo, o método clickOnView engolia SecurityExceptions).

Ao contrário da resposta anterior, o Espresso é compatível com todas as versões da API com um número significativo de usuários (consulte: http://developer.android.com/about/dashboards/index.html ). Funciona em algumas das versões mais antigas, mas testá-las seria um desperdício de recursos. Falando em testes ... O Espresso é testado em todas as alterações por um conjunto de testes abrangente (com mais de 95% de cobertura), bem como a maioria dos aplicativos Android desenvolvidos pelo Google.

O Espresso é muito mais rápido que o Robotium, mas só funciona em algumas versões do SDK.

Portanto, se você deseja um teste que funcione em todos os dispositivos, escolha o Roboitum. Caso contrário, opte pelo expresso e não se esqueça que ainda será um testador beta por um bom tempo.