La mejor manera de ejecutar pruebas rápidas de JUnit en un proyecto Android en Android Studio
Tengo algunas sencillas clases de Java y sencillas pruebas JUnit en mi proyecto de Android Studio. Actualmente viven dentro de mi módulo Android. Si los ejecuto como pruebas de Android pasan bien, pero son realmente lentos, ya que requiere iniciar o conectarse al emulador.
Si intento ejecutar uno como una prueba JUnit, me golpeó el !!! JUnit version 3.8 or later expected
!!! JUnit version 3.8 or later expected
JUnit problema de la versión. Esta respuesta explica cómo solucionar el problema. Desafortunadamente, entonces golpeé el java.lang.NoClassDefFoundError: junit/textui/ResultPrinter
, que no puedo figurar hacia fuera cómo fijar.
- Prueba de la unidad Android - Problemas de resolución y verificación
- Prueba de unidad Android: ¿Cómo hacer que una clase sea más comprobable?
- Prueba de DialogFragments con Robolectric
- Error en el corredor al realizar pruebas con Robolectric
- Android TestRunner falla debido a la excepción de IllegalState
Entonces intenté mover mis pruebas de JUnit en un módulo separado de Java que depende del módulo androide. Todo se compila bien. He añadido una nueva configuración para iniciar las pruebas JUnit (: MyJUnitTests: test), pero las pruebas fallan con el package com.myproject.util does not exist
. Parece que tal vez el classpath no está incluyendo las clases del módulo Android dependiente.
¿Alguien sabe cómo solucionar este problema classpath? He mirado muchas respuestas relacionadas y ninguna de ellas parece funcionar para mí. ¿O es una mala idea intentar mantener mis pruebas de JUnit en su propio módulo?
Puedo obtener las pruebas de JUnit para correr rápido y pasar si muevo mis clases de Java simples y sus pruebas de JUnit en un módulo completamente separado (por ejemplo, aquí ), y revertir la dependencia para que el módulo de Android depende del módulo de Java. ¿Es esa la solución preferida?
- No se pudieron determinar las dependencias para todas las tareas con robolectric gradle plugin
- Robolectric InflateException al usar el diseño de barra de acción personalizada
- ¿Cómo volver a ejecutar la prueba fallada en Espresso? - lluvia de ideas
- Android Eclipse Plugin: Prueba de Instrumentación Runner no especificado
- Cómo obtener la salida de registro de Android mostrada con las pruebas de JUnit (utilizando JUnit nativo sin emulador)
- Prueba de Android Realm con RxJava - "abierto desde un hilo sin un Looper" Excepción
- Proyecto de biblioteca de prueba autónoma no puede encontrar las clases de biblioteca
- Cómo proporcionar archivos de datos para las pruebas de unidad de Android
El problema básico es que las clases de Android Framework no funcionan bien fuera del contexto del sistema operativo Android, por lo que cualquier código que tenga dependencias de las clases Framework no se ejecuta en un entorno JUnit regular, tal y como se ha encontrado.
Su solución de intentar mover las pruebas de JUnit en un módulo separado no funcionará porque no puede tener un módulo Java sencillo dependiendo de un módulo de Android. Los módulos de Android Gradle no actúan como módulos de Java, porque las compilaciones de Android son mucho más complejas y porque el resultado final de una construcción de módulo de Android será un APK o un AAR, que otros tipos de módulo no entenderán.
Si puede mover sus clases simples de Java y pruebas de unidad en un módulo Java simple y tener los módulos de Android dependen de eso, será el mejor enfoque que obtendrá el mayor apoyo de las características oficiales en el IDE. También tendrá un beneficio arquitectónico en que mantendrá esas clases libres de las abstracciones de Android, haciéndolo más portátil, e impondrá una separación de la lógica empresarial de la interfaz de usuario o de almacenamiento u otras cosas más específicas del dispositivo.
Si eso es difícil de hacer, muchos desarrolladores en sus zapatos van con Robolectric , que es un arnés de prueba que permite que el código dependa de muchas partes del Framework Android para ejecutarse en un entorno JUnit sin un emulador o dispositivo. No es oficialmente compatible con Google, pero Google es consciente de que es ampliamente utilizado y se esfuerza por no romperlo sin querer.
- Editado
- ¿Cuál es la diferencia entre isDeviceLocked y isKeyguardSecure en el KeyguardManager de android?