Desarrollo impulsado por pruebas para Android

¿Podemos usar JUnit para desarrollo orientado a pruebas en Android? Si no, ¿existe una alternativa similar a JUnit?

Busqué un poco en google y también leí un post SO Android Driven Development Driven Parece que Android nunca se hizo con TDD en mente. Quería estar seguro antes de comenzar a aprender TDD y desarrollar Android al mismo tiempo.

Sí, podemos usar JUnit para el desarrollo impulsado por pruebas. Para iniciar con usted puede consultar el siguiente enlace: http://developer.android.com/tools/testing/testing_android.html#JUnit Siguiendo la documentación podemos usar junit.framework para hacer pruebas de unidad.

Creo que puede confiar completamente en Robolectric para ejecutar sus pruebas en JVM. Puede usar JUnit4 para probar sus POJOs y Robolectric le proporciona el soporte para probar los componentes de Android.

También soy un principiante en TDD para Android Development. Encuentro Robolectric muy útil para probar mi código.

Este video le dirá casi todo lo que le proporciona para la prueba de unidad del código de Android.

ACTUALIZACIÓN: Con el soporte del estudio de Android y el nuevo ecosistema de Android, las pruebas de unidad ahora se puede hacer como una práctica de primera clase. Consulte http://developer.android.com/training/testing/unit-testing/local-unit-tests.html para obtener más detalles.

Hay un par de buenas aproximaciones a la impulsión de prueba el código de androide. Los más efectivos que he encontrado hasta ahora son el MVVM (model-view-viewmodel) o MVP (model-view-presenter), donde la lógica de negocio así como la lógica de presentación se desacoplan de la vista y pueden ser fácilmente unidades Probado

Aquí hay un poco de explicación del espacio del problema: http://www.techwell.com/2013/04/applying-test-driven-development-android-development

La conclusión es que usted debe utilizar Robolectric. Desafortunadamente Robolectric es lento, y si sigues TDD incluso en un nivel pragmático, terminarás con un par de cientos de pruebas, que correrán por un par de 10 segundos. Y eso no es lo que quieres hacer con TDD. El paquete de prueba TDD debe ejecutarse como máximo en segundos.

Mi consejo es:

  • Cree clases de contenedor alrededor de las clases de Android que simplemente llaman a la clase de Android.
  • Escribe la lógica de tu aplicación en Java puro.
  • Utilice Junit (o TestNG o lo que le plazca) para probar su modelo / lógica de negocio
  • Utilice ocasionalmente Robolectric para las clases del envoltorio (probablemente usted no tendrá que utilizar)
  • (Puede escribir pruebas de integración que utilizan varias clases, Robolectric, etc., pero sólo ejecutarlo en un servidor de Integración Continua independiente, por ejemplo, cada hora)

Con este enfoque su lógica será más portátil también.

  • Android Studio + Robolectric + Gradle Class Not Found Excepción
  • Uso de una carpeta de recursos en el proyecto de prueba para datos de cadena de prueba
  • ¿Es posible entrar en el modo de depuración para android cuando se ejecuta junit test?
  • Googletest para Android NDK
  • ¿Utilizando Inyección de Dependencia con Roboguice?
  • Prueba de componente en Android App SDLC?
  • Unidad de pruebas de las clases de Android realista. Entorno de prueba, ciclo de vida y respuestas
  • Cómo configurar Robolectric en Android Studio 1.0
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.