Google Espresso o Robotium [cerrado]

115

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?

Androidme
fuente
19
Honestamente, odio cuando la gente vota en contra sin escribir ningún comentario. Agradecería que la persona que vota en contra escribe algunos comentarios sobre por qué está haciendo eso
Androidme
8
Creo que la pregunta es muy útil. Muchos desarrolladores se preguntan esto a sí mismos. ¿Cuáles son las diferencias? Creo que el problema es la forma en que lo preguntas. Debe preguntarlo con más detalle y no solo preguntar cuál usar.
tasomaniac
8
Esta es la pregunta exacta que quería responder. Gracias por publicar
Richard Fung
8
No me gusta el hecho de que esto esté fuera de tema según StackOverflow. Sé que si tuviéramos que comparar cada biblioteca y herramienta, podría haber muchas respuestas basadas en opiniones, pero una pregunta como esta que pregunta por las diferencias entre dos recursos es muy útil.
David Argyle Thacker

Respuestas:

175

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.

ValeraZakharov
fuente
Hola ! Gracias por tu respuesta, ¿Espresso ofrece la posibilidad de probar varias aplicaciones en el mismo caso de prueba? Tengo que probar mi aplicación que llama a una actividad de otra aplicación (mi otra aplicación que comparte el mismo sharedUserId) y luego recupera el resultado. No puedo hacer eso con Robotium, pero ¿tal vez con Espresso? :-)
nbe_42
1
No, no puede interactuar con la interfaz de usuario fuera de su proceso con Espresso. Esta es una limitación del marco de instrumentación.
ValeraZakharov
1
@ValeraZakharov :: ¡¡Hola ... !! Como dijiste, espresso se encargará de la sincronización de subprocesos de la interfaz de usuario y no es necesario poner Sleeps. Pero en mi caso, he escrito algunos casos de prueba y todos los casos de prueba funcionan en mi máquina local (con un sueño por TestSuite como inicio). Pero casi el 99% de los casos de prueba están fallando cuando ejecuto con jenkins local / servidor. He desactivado todas las animaciones en el emulador de jenkins. La mayoría de las veces obtengo AppNotIdleException. No puedo averiguar la causa raíz. ¿Puedes ayudarme?
Naresh Gunda
@Radu Lo he hecho. Su comentario es nulo y sin una explicación adecuada parece un intento imprudente de llamar la atención.
Rakib
9

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.

Snicolas
fuente
Un voto a favor me ayudaría a crear un sinónimo para esta etiqueta ..;)
Snicolas
2
Enlace anterior cambiado, este es el nuevo: google.github.io/android-testing-support-library/docs/espresso/…
Evin1_