android - test - robolectric config manifest

Robolectric vs Android Test Framework

Question

¿ Robolectric proporciona algún beneficio claro en comparación con Android Test Framework ? He leído los documentos sobre ambos frameworks pero, por lo que puedo ver, el único beneficio claro con respecto a Robolectric es que se ejecuta en JVM en lugar de hacerlo en DalvikVM, lo que lo hace más rápido que Android framework.

¿Hay otros beneficios importantes que se destacan?

Answer 1

El principal beneficio de Robolectric es la velocidad. Las pruebas unitarias con Robolectric no requieren un emulador o dispositivo en ejecución para ejecutar las pruebas y, por lo tanto, son mucho más rápidas.

Es posible que desee tener un conjunto de pruebas de integración que se ejecutan en un dispositivo real, solo un conjunto mucho más pequeño.

Answer 2

Para compartir cómo lo hago ...

Robolectric Para SQL, flujo de actividades para aquellos objetos que necesitan contexto.

JUnit4 para el módulo java de api para asegurarse de que los datos se devuelvan correctamente.

Espresso Para verificar la visualización de la interfaz de usuario correctamente.

Cuando modifiqué api ... solo ejecuto jUnit4.

Cuando modifiqué el enlace de datos entre api y UI o Sqlite, solo ejecutaré Robolectric.

Cuando modifiqué UI, solo ejecuté Espresso.

A veces voy a ejecutar Robolectric y Espresso juntos, pero muy raro.

Pero voy a ejecutar todo antes de publicar para jugar en la tienda.

Porque creo que no hay un beneficio real por ahora. Pero vea cómo lo usa para acelerar la calidad de su producto y la velocidad de desarrollo.

Corrígeme si estoy equivocado.

Answer 3

Actualización de abril de 2015 : las herramientas de compilación de Gradle y Android Studio ahora admiten oficialmente las pruebas unitarias y evitan que android.jar arroje un error de trozo (sin implementación real). Entonces, sí, es posible ejecutar pruebas en Java VM, cuando los stubs se mocked apropiada. Es un comienzo, pero aún no es comparable con la potencia de Robolectric. También hay una tercera alternativa, Desplácese hasta el final de esta respuesta.

Ahora, sobre Robolectric:

Pros : aquí hay algunos puntos sobre cómo ha demostrado ser útil en pruebas unitarias:

1. No necesita ejecutar un emulador, por lo que puede probar algunas de las partes no relacionadas con la IU del proyecto sin requerir un emulador o dispositivo. Esto también se aplica a la ejecución de pruebas en servidores de integración / compilación continua, no es necesario iniciar instancias de emulador.

2. Con Android Studio, puede ejecutar rápidamente una clase de prueba particular, cuando está trabajando en la implementación para satisfacer los casos de prueba. Puede depurar a medida que escribe el código. Esta es una ganancia de productividad masiva.

3. Se puede falsificar casi todas las cosas relacionadas con Android como objetos de sombra, incluso SQLite. Además, cada objeto sombra expone muchas funciones útiles que sus homólogos androides normales no ofrecen. Con las contrapartes de shadow Objeto Android, puede hacer una comprobación interna o llamar a métodos especiales.

4. Realmente brilla cuando se prueban códigos multihilo como AsyncTask s, Loopers y Handlers etc. Puedes pausar y adelantar thread Loopers, incluso el hilo principal. Excelente para las pruebas de devolución de llamada basadas en Handler.

5. Formato JUnit 4 compatible. Android todavía se mantiene en JUnit 3 la última vez que lo verifiqué.

6. Se puede combinar con otras herramientas de prueba como Mockito, Espresso, etc.

7. Admite la creación de instancia de actividad simulada Robolectric.buildActivity() y su control a través de ActivityController . La manipulación de Fragmentos / Vistas también funciona en tales instancias de actividad falsa.

8. Ahora se proporcionan módulos complementarios que cubren múltiples dex, v4-support, servicios de juego, mapas y cliente http también. Por lo tanto, ahora es fácil de probar el código usando estas funciones de la biblioteca también.

Contras : Donde lo encontré no tan bueno:

1. Robolectric sobresale en ayudar a las pruebas de la Unidad, pero no cubre todas las funcionalidades que un dispositivo o emulador real puede ofrecer. Por ejemplo, sensores, gps, open-gl, etc.

2. Necesitarás un emulador o dispositivo real al realizar pruebas de integración o UI, para que las actividades y los servicios puedan interactuar con el entorno Android completo (otras aplicaciones, como usar la aplicación de cámara para obtener una imagen para tu aplicación), no una limitada. Aquí tendrá que usar el marco de prueba predeterminado ya que también tiene funciones para probar la IU.

3. La carga de JNI parece no ser compatible. Por lo tanto, el código con dependencia nativa no se puede probar.

4. A partir de ahora, Robolectric tiene una dependencia de cable duro en google maps jar para funcionar. Y descargará otro android.jar de maven. Entonces, la configuración del proyecto puede requerir un poco de retoques. Actualización: a partir de v3, parece extraer todas las dependencias a través de Gradle sin mucho alboroto.

5. Las herramientas más nuevas de Android admiten cobertura e informes de generación, etc., pero solo cuando las pruebas se ejecutan en un dispositivo. Entonces con Robolectric tendrás que crear tareas adicionales de Gradle (ejecutar Jaococ) para hacerlo por ti. Actualización: Gradle 2.9 + se envía con el complemento jacoco.

6. Como las herramientas de compilación gradle y android están enviando versiones de compilación más nuevas a un ritmo rápido, las versiones estables de Robolectric a veces comenzarán a tener problemas con las herramientas de compilación modificadas. La mayoría de los problemas típicos incluyen: versión sdk incompatible, manifiesto no encontrado, rutas de salida de compilación no coinciden, recursos no cargados, problemas de configuración de compilación, etc. Algunos problemas también están relacionados con errores en las herramientas de Android. En ocasiones, es posible que incluso tenga que escribir su propio corredor de pruebas personalizado o aplicar soluciones provisionales hasta que la próxima versión corrija esos problemas. Verifique los problemas abiertos y configure las pruebas en consecuencia.

Otra alternativa es simplemente imitar cosas por su cuenta, sin marcos involucrados. Es el "camino difícil" pero la forma más personalizable. Es simple JUnit con JMockit:

@RunWith(JMockit.class)
public class OtherTest {
public void testHandlerCallback(@Mocked final FragmentTransaction transaction,
@Mocked final FragmentManager manager,
@Mocked final Activity activity,
@Mocked final LayoutInflater inflater,
@Mocked final ViewGroup parent) {
final List<Fragment> fragments = new ArrayList<>();
new Expectations() {{
activity.getFragmentManager(); result = manager;
manager.beginTransaction(); result = transaction;
transaction.add(withCapture(fragments), anyString);
transaction.commit(); result = new Delegate<Void>() {
public int commit() {
View v = fragments.get(0).onCreateView(inflater,parent,null);
Deencapsulation.invoke(v,"onMeasure",0,0);
return 0;
}
};
}};
}
}

Arriba hay un ejemplo crudo y en línea. En realidad, puede crear clases reutilizables adecuadas (digamos FragmentTestHarness ) que tomarán un componente (digamos un Fragment ) bajo prueba y lo envolverán en un entorno completamente aislado, preparándolo para las pruebas.