android - tester - Google Espresso o Robotium

pruebas de instrumentacion android

Question

Tengo que usar la herramienta de prueba automatizada de interfaz de usuario y estoy confundido entre el uso de Robotium vs Google Espresso.

¿Cuáles son las principales diferencias entre los dos? ¿Hay características que existen en una pero no en la otra?

Answer 1

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

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

En Google, comenzamos utilizando Robotium porque era más conveniente que la instrumentación de stock (se burla de los desarrolladores de Robotium por hacerlo). Sin embargo, no satisfizo nuestra necesidad de un marco que facilitara la escritura de pruebas fiables para los desarrolladores.

Los principales avances en Espresso sobre Robotium:

1. Sincronización. De manera predeterminada, la lógica de prueba de instrumentación se ejecuta en un subproceso diferente (instrumentación) que las operaciones de UI (procesadas en el subproceso de UI). Sin la sincronización de las operaciones de prueba con actualizaciones de UI, las pruebas serán propensas a fallas, es decir, fallarán aleatoriamente debido a problemas de tiempo. La mayoría de los autores de las pruebas ignoran este hecho, algunos agregan mecanismos de inactividad / reintento e incluso implementan código de seguridad de subprocesos más sofisticado. Ninguno de estos son ideales. Espresso se ocupa de la seguridad de los hilos sincronizando sin problemas las acciones de prueba y las aserciones con la interfaz de usuario de la aplicación bajo prueba. Robotium intenta solucionar esto con mecanismos de reinicio / reinicio, que no solo no son 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. Usted le dice al marco cómo ubicar un elemento de IU usando emparejamientos estándares de Hamcrest 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. Borrar información de falla. Espresso se esfuerza por proporcionar una rica información de depuración cuando ocurre una falla. Además, puede personalizar la manera en que Espresso maneja las fallas con su propio manejador de fallas. No lo he intentado en un tiempo, pero las versiones anteriores de Robotium sufrieron un manejo de fallas inconsistente (por ejemplo, el método clickOnView se tragaría las excepciones de seguridad).

A diferencia de una respuesta anterior, Espresso es compatible con todas las versiones de API con un número significativo de usuarios (ver: 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 es probado en cada cambio por 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.

Answer 2

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

Entonces, si quieres una prueba que funcione en todos los dispositivos, ve a Roboitum. Si no es así, vaya por café expreso, y no olvide que será un beta tester durante algún tiempo.