2011-06-07 13 views
44

Tengo mucha experiencia en la creación de aplicaciones para Android. Para mi nuevo proyecto, hemos decidido realizar Test Driven Development (TDD). Me he mojado las manos en Robotium para User Scenario Testing, y funciona bien y parece fácil también.Android Drive Driven Development

Para probar la unidad, traté de simular Context usando (MockContext Android Class) pero no puedo hacerlo. Revisé este blog http://sites.google.com/site/androiddevtesting/ y este http://sdudzin.blogspot.com/2011/01/easy-unit-testing-for-android.html, que sugiere que la burla en las aplicaciones de Android todavía es muy limitada y difícil, y he sugerido utilizar PowerMock, jMockit, JeasyTest o Roboelectric (en combinación con Mockito y Maven) e incluso RoboGuice.

Me gustaría recibir cualquier sugerencia de ustedes sobre qué marco de pruebas unitarias en su opinión es el mejor para probar aplicaciones de Android. (particularmente probando clases de Android, posiblemente dando contextos falsos y otras características de burla para que pueda hacer que mis casos de prueba sean lo más independientes posible). Cualquier sugerencia o sugerencia sería útil. Gracias

+1

ver también [Recursos para TDD en Android] (http://stackoverflow.com/questions/2336488/resources-for-tdd-on-android) – rds

+1

Consulte también [Mejores prácticas para probar unidades de aplicaciones de Android] (http://stackoverflow.com/questions/522312/best-practices-for-unit-testing-android-apps) – rds

Respuesta

30

Para las pruebas fuera de dispositivo, mira Robolectric

Para las pruebas en el dispositivo, mira Borachio

En pocas palabras: es todavía muy, muy difícil de hacer bien. Las cosas están mejorando (la situación es dramáticamente mejor hoy que hace 6 meses), pero Android es cómodamente el entorno más hostil a las pruebas para el que he escrito programas.

+3

Borachito está en desuso. [Mockito ahora tiene soporte para Android] (http: //www.paulbutcher.com/2012/05/mockito-on-android-step-by-step /) – rds

+3

9 meses más tarde, ¿alguna actualización de esto? –

+0

¿Alguna sugerencia para Espresso? –

4
  • Utilizo ActivityInstrumentationTestCase2 en el caso de Actividades para TDD (o BDD), y escribo pruebas de unidades normales para toda la lógica. Esto también me ayuda a separar la lógica de las actividades.
  • Las aplicaciones móviles, por naturaleza, están centradas en la IU. Por lo tanto, no es tener sentido para burlarse de la interfaz de usuario, incluso si hace que la prueba de la unidad se vea como como una prueba funcional.
  • Para agregar Extras a los intentos, puede establecer un intento personalizado para la prueba o hacerlo para todas las pruebas anulando la configuración.
  • Los burladores provocan muchos problemas en Android, así que utilizo stubs.

A continuación se proporciona un ejemplo. La actividad muestra Hello World cuando hace clic en un botón -

public class HelloWorldActivityTest extends 
     ActivityInstrumentationTestCase2<HelloWorldActivity> { 

    private HelloWorld activity; 

    public HelloWorldActivityTest() { 
     super(HelloWorldActivityTest.class); 
    } 

    public void testShouldRenderGreetingOnButtonClick() { 
     activity = this.getActivity(); 
     Button button = (Button) activity.findViewById(R.id.btn_greet); 
     TouchUtils.clickView(this, button); 
     assertEquals("Hello World!", 
       ((TextView) activity.findViewById(android.R.id.greeting_text)) 
         .getText()); 
    } 

} 

EDIT: Las cosas han cambiado desde que envió la respuesta. Mockito ahora tiene un soporte razonablemente bueno para Android. Y para las pruebas, pasamos de ActivityInstrumentationTestCase2 a Robolectric, solo para aprovechar la velocidad de JVM en la fase de desarrollo. Android Testing Framework es ideal para la integración y las pruebas funcionales, pero no para las pruebas unitarias.

17

Para hacer TDD en Android, yo personalmente uso todos los siguientes:

  • assertj-android: afirmaciones para Android
  • Mockito: marco de burla
  • Robolectric: marco de pruebas de unidad que funciona sin la necesidad de Emulador de Android
  • Robotium: pruebas de IU (Necesita emulador o dispositivo para ejecutar)

También: El uso de bibliotecas de inyección de dependencias como Dagger o Roboguice simplificará en gran medida las pruebas de unidad/integración. Para ejecutar pruebas en varios dispositivos, considere usar Spoon.

+5

En mi opinión, no deberíamos tratar las pruebas de instrumentación de Robotium como parte de TDD. Una de las reglas básicas de TDD es que las pruebas deberían proporcionar retroalimentación en segundos.
Estoy de acuerdo en que las pruebas de Robotium/Espresso etc. también son importantes, pero es imposible usarlas en el proceso TDD Red-Green-Refactor. –

+0

gracias por estos enlaces, pero FEST-android se ha ido: ahora hay https://github.com/square/assertj-android que es un tenedor de Fest Assert – vallllll

+0

@vallllll gracias, actualizó el enlace – Nima

2

Para aplicar TDD para android, Android Testing Codelab será de gran ayuda para usted. Code lab muestra el uso de la herramienta de prueba y cómo puede aplicar TDD para Android. Lo probé y fue muy útil para mí.

Bono: Check Clean Architecture

0

tenemos

https://developer.android.com/training/testing/start/index.html

y puede poner a prueba locales (se ejecuta en la JVM) e instrumental de prueba (Se ejecuta en el dispositivo o emulador)

Para esto tenemos que agregar

Android Testing Support Library 

El SDK de Android incluye dos herramientas para el nivel funcional de pruebas de aplicaciones

Mono y monkeyrunner

1

Android Testing Support Library proporciona un amplio marco para probar aplicaciones de Android. Esta biblioteca proporciona un conjunto de API que le permiten crear rápidamente y ejecutar código de prueba para sus aplicaciones, incluidas JUnit 4 y pruebas de interfaz de usuario funcional (UI). Puede ejecutar pruebas creadas con estas API desde el IDE de Android Studio o desde la línea de comandos.

Leer más sobre: ​​

Gracias :)

Cuestiones relacionadas