unit - ¿Diferencia entre la prueba de instrumentación de Android y la prueba de unidad en Android Studio?

testing aplicaciones moviles

Question

A partir de Android Studio 1.1rc hay soporte para pruebas de unidades y me pregunto cuál es la diferencia entre las pruebas de instrumentación de Android y las pruebas unitarias.

Como yo lo entiendo:
Las pruebas unitarias son útiles para probar código que no llama a la API de Android, y las pruebas de instrumentación de Android son más bien pruebas de integración para probar elementos específicos de API de Android o componentes de GUI.

Sin embargo, si usa un marco como Robolectric o Mockito en las pruebas de su unidad, puede probar el código de Android (sin necesidad de un dispositivo) si no me equivoco.

¿Es esto correcto, o hay una diferencia más grande? Si es así, ¿cuál es el uso de cada uno?

Answer 1

Me parece que las pruebas de instrumentación son pruebas de integración con la capacidad de controlar el ciclo de vida y los eventos (onStart, onCreate, etc.) de la aplicación.

Las pruebas unitarias, tal como lo entiendo, están probando una Unidad (por ejemplo, una Clase) por sus datos y comportamiento.

Por ejemplo, supongamos que tienes un juego: este juego se ejecuta en una actividad (actividad principal) y tienes un personaje basado en una clase de robot, que tiene 2 métodos (fuego y movimiento). Probarías la actividad principal con una prueba de instrumentación para ver si se guarda correctamente cuando salgas de la aplicación, si se restablece correctamente cuando la restaures, etc. y probarás Robot con una prueba de Unidad para probar sus atributos y comportamiento.

Descargo de responsabilidad: no soy una persona de Java, pero me interesó su pregunta y la contesté en función de una búsqueda menor en línea. Probablemente tengas que profundizar más en esto para encontrar una respuesta más detallada.

Answer 2

https://developer.android.com/training/testing/fundamentals.html#testing-pyramid

Las pruebas pequeñas son pruebas unitarias que puede ejecutar de manera aislada de los sistemas de producción. Por lo general, se burlan de todos los componentes principales y deben ejecutarse rápidamente en su máquina.

Las pruebas medianas son pruebas de integración que se encuentran entre las pruebas pequeñas y las pruebas grandes. Integran varios componentes y funcionan con emuladores o dispositivos reales.

Las pruebas grandes son pruebas de integración y UI que se ejecutan al completar un flujo de trabajo de IU. Aseguran que las tareas clave del usuario final funcionen como se esperaba en emuladores o dispositivos reales.

Answer 3

Examen de la unidad

Funciona solo en la máquina local.

Caso de prueba de instrumentación

Se ejecuta en el dispositivo o emulador de Android. Si comprueba el caso de prueba, se ejecuta en un emulador o dispositivo Android

Answer 4

EXAMEN DE LA UNIDAD

Pruebas unitarias que se ejecutan solo en su máquina local. Estas pruebas se compilan para ejecutarse localmente en la JVM para minimizar el tiempo de ejecución. Utilice este enfoque para ejecutar pruebas unitarias que no tienen dependencias en el marco de Android o tienen dependencias que los objetos simulados pueden satisfacer.

Entonces, básicamente, ejecutas el código Java simple para probar, por ejemplo, un proveedor de contenido, conexiones de bases de datos, entradas y salidas de métodos. Esto no funciona en Android. Para ejecutarlo NO necesitas un dispositivo.

PRUEBA DE INSTRUMENTACIÓN

Pruebas unitarias que se ejecutan en un dispositivo Android o emulador. Estas pruebas tienen acceso a la información de Instrumentación, como el contexto de la aplicación bajo prueba. Utilice este enfoque para ejecutar pruebas unitarias que tienen dependencias de Android que los objetos de simulación no pueden satisfacer fácilmente.

Por lo tanto, se burla de cómo el usuario utilizará la aplicación real, por lo que NECESITA un dispositivo (físico o emulador) para ejecutarlo. Tiene acceso a vistas, actividades, contexto, etc.

Referencia: http://developer.android.com/tools/testing/testing_android.html

Answer 5

Examen de la unidad:

A menudo , las pruebas unitarias se conocen como "pruebas locales" o "pruebas de unidades locales". La razón principal de esto parece ser que desea poder ejecutar pruebas sin un dispositivo o un emulador adjunto.

Las pruebas unitarias no pueden probar la interfaz de usuario de su aplicación sin burlarse de objetos como una actividad.

Pruebas de instrumentación:

Las pruebas de instrumentación se ejecutan en un dispositivo o un emulador. En segundo plano, su aplicación se instalará y luego también se instalará una aplicación de prueba que controlará su aplicación, la ejecutará y ejecutará pruebas de interfaz de usuario según sea necesario.

Las pruebas de instrumentación también se pueden usar para probar ninguna lógica de UI. Son especialmente útiles cuando necesita probar código que tiene una dependencia en un contexto.

Ref link por ejemplo

Answer 6

Las pruebas unitarias aíslan el componente bajo prueba, y esta es la razón por la que a menudo se usan junto con frameworks Mocks como Mockito: porque aíslan la unidad de sus dependencias. Tenga en cuenta que lo que dice respecto a la API de Android es parcialmente cierto, porque también hay pruebas de Unidad instrumentada , es decir, la instrumentación también forma parte del paquete Junit , y también las clases que extienden TestCase, ya que la clase AndroidTestCase es parte del paquete Junit pero permite el uso de A) Contexto, al que puedes llamar con getContext (), y B) ¡Recursos que son parte de la API de Android! También, tenga en cuenta que AndroidTestCase es una clase base y hay varias otras clases bastante útiles que extienden esta clase. Prueban específicamente Cargadores, ContentProviders e incluso Servicios y también tienen acceso a la API de Android. estas clases proporcionan el marco de prueba de JUnit y los métodos específicos de Android. Ahora con Junit4 existe ServiceTestRule que se extiende directamente desde Object y le permite probar un servicio más fácilmente, aunque no puede iniciar un Intent directamente dentro de esta clase.

Las pruebas de instrumentación también están en el paquete Junit, pero el control de la API de Android es bastante total porque las Pruebas de Instrumentación se instancian en el sistema antes de que se ejecute cualquier código de aplicación, y para probar debes abrir la aplicación real (emulador o teléfono conectado con USB). Acceden a los componentes de Android (por ejemplo, haga clic en un botón) y al ciclo de vida de la aplicación, generalmente son más lentos que las pruebas Junit que extienden TestCase (los examinados anteriormente), el uso típico es con ActivityInstrumentationTestCase2 que tiene un enfoque de prueba funcional, más orientado al usuario.

EDITAR: Con respecto a Roboelectric y Mockito, que se combinan con Espresso entre los frameworks de prueba más populares en este momento (13 de julio de 2016), Roboelectric le permite ejecutar múltiples pruebas en segundos en lugar de minutos, y esto resulta muy útil en equipos que tienen que ejecuta pruebas continuas y está sujeto a una integración continua.

Desde el sitio de Robolectric:

Un enfoque alternativo a Robolectric es usar marcos simulados como Mockito o burlarse del SDK de Android. Si bien este es un enfoque válido, a menudo produce pruebas que son esencialmente implementaciones inversas del código de la aplicación. Roboelectric permite un estilo de prueba más cercano a las pruebas de caja negra, lo que hace que las pruebas sean más efectivas para la refactorización y permite que las pruebas se centren en el comportamiento de la aplicación en lugar de en la implementación de Android. Todavía puede utilizar un marco de burla junto con Robolectric si lo desea.

Mockito que también se puede usar con Junit, se usa realmente con la excepción de cuando tienen que administrar clases finales, clases anónimas o tipos primitivos.