Google Espresso o Robotium [cerrado]

Tengo que usar la herramienta de prueba de IU automatizada y estoy confundido entre usar Robotium o Google Espresso.

¿Cuáles son las principales diferencias entre los dos? ¿Hay características que existen en uno pero no en el otro?

Divulgación completa: soy uno de los autores de Espresso.

Tanto Espresso como Robotium son marcos basados ​​en instrumentación, lo que significa que usan instrumentación de Android para inspeccionar e interactuar con las actividades bajo prueba.

En Google, comenzamos usando Robotium porque era más conveniente que la instrumentación de stock (felicitaciones a los desarrolladores de Robotium por hacerlo así). Sin embargo, no satisfizo a nuestra necesidad de un marco que hizo que la escritura fiables las pruebas de fácil para los desarrolladores.

Los principales avances de Espresso sobre Robotium:

1. Sincronización. De forma predeterminada, la lógica de prueba de instrumentación se ejecuta en un subproceso (instrumentación) diferente al de las operaciones de la IU (procesadas en el subproceso de la IU). Sin la sincronización de las operaciones de prueba con las actualizaciones de la interfaz de usuario, las pruebas serán propensas a fallar, es decir, fallarán aleatoriamente debido a problemas de sincronización. La mayoría de los autores de pruebas ignoran este hecho, algunos agregan mecanismos de suspensión / reintento y aún menos implementan un código de seguridad de subprocesos más sofisticado. Ninguno de estos es ideal. Espresso se ocupa de la seguridad de los subprocesos sincronizando sin problemas las acciones de prueba y las afirmaciones con la interfaz de usuario de la aplicación bajo prueba. Robotium intenta abordar esto con mecanismos de suspensión / reintento, que no solo son poco confiables, sino que también hacen que las pruebas se ejecuten más lentamente de lo necesario.

2. API. Espresso tiene una API pequeña, bien definida y predecible, que está abierta a la personalización. Le dice al marco cómo ubicar un elemento de la interfaz de usuario utilizando los comparadores de Hamcrest estándar y luego le indica que realice una acción o verifique una afirmación en el elemento de destino. Puede contrastar esto con la API de Robotium, donde se espera que el autor de la prueba elija entre más de 30 métodos de clic. Además, Robotium expone métodos peligrosos como getCurrentActivity (¿qué significa actual de todos modos?) Y getView, que le permiten operar en objetos fuera del hilo principal (consulte el punto anterior).

3. Información clara de fallas. Espresso se esfuerza por proporcionar información de depuración completa cuando ocurre una falla. Además, puede personalizar la forma en que Espresso maneja las fallas con su propio controlador de fallas. No lo he probado en un tiempo, pero las versiones anteriores de Robotium sufrían de un manejo de fallas inconsistente (por ejemplo, el método clickOnView se tragaba SecurityExceptions).

A diferencia de una respuesta anterior, Espresso es compatible con todas las versiones de API con un número significativo de usuarios (consulte: http://developer.android.com/about/dashboards/index.html ). Funciona en algunas de las versiones anteriores, pero probarlas sería una pérdida de recursos. Hablando de pruebas ... Espresso se prueba en cada cambio mediante un conjunto de pruebas integral (con más del 95% de cobertura), así como la mayoría de las aplicaciones de Android desarrolladas por Google.

Espresso es mucho más rápido que Robotium, pero solo funciona en algunas versiones de SDK.

Entonces, si desea una prueba que funcione en todos los dispositivos, elija Roboitum. Si no es así, opte por un espresso y no olvide que será un beta tester durante algún tiempo.