ActivityUnitTestCase y startActivity

En el JavaDoc de ActivityUnitTestCase dice:

No llame desde el método setUp (). Debe llamar a este método de cada uno de sus métodos de prueba.

¿No es poner algo en cada método de prueba equivalente a ponerlo en setUp , teniendo en cuenta que toda la idea detrás de ese método es hacer exactamente eso, es decir, ejecutar algo antes de cada prueba?

Además, ¿por qué no se nos permite hacer eso? Lo intenté, y funciona muy bien.

Parece que setUp se ejecuta con el cargador de clases del proyecto de prueba, mientras que los métodos de prueba reales se ejecutan con la aplicación en el cargador de clases de la prueba. Véase, por ejemplo, esta discusión en la lista de correo de RoboGuice:

http://groups.google.com/group/roboguice/browse_thread/thread/2e129f87ead10b10

¿Por qué este es el caso, no estoy seguro (parece una decisión de diseño muy extraño para mí). Pero el resultado es que no se puede acceder a nada en la aplicación bajo prueba en el método setUp. Que se mueve setUp en el territorio de la tetera de chocolate.

Tenga en cuenta que esta restricción no se aplica si está probando un proyecto de biblioteca como se describe aquí:

http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/

Porque en ese caso las pruebas y el código bajo prueba están todos en una sola aplicación.

Puede tener algo que ver con el hecho de que startActivity ejecuta el método onCreate de la actividad en el hilo actual (instrumentación), en lugar de cambiarlo al subproceso de UI: http://google.com/codesearch#uX1GffpyOZk/test-runner/src /android/test/ActivityUnitTestCase.java&l=103 . Si anota sus métodos de prueba con @UiThreadTest, entonces se ejecutará en el subproceso de interfaz de usuario, pero setUp no, lo que podría explicar la instrucción.

Creo que la razón que dicen que es más de una "mejor práctica" que una razón técnica dura y rápida (nota: podría estar equivocado sobre eso). La razón es que si cada método de prueba individual es esencialmente autónomo, es más fácil crear diferentes conjuntos de pruebas que realizarán las pruebas EXACT que necesita en lugar de ejecutar todas las pruebas de ActivityTestCase en setUp ().

  • Sala de pruebas de unidad y LiveData
  • Googletest para Android NDK
  • ¿La forma más simple de probar una unidad de una aplicación de la biblioteca de Android?
  • Cómo probar la interacción simulada en Activity onResume () ¿Utilizando Dagger Modules y Robolectric?
  • No se puede resolver la actividad para: Intención
  • ActivityInstrumentationTestCase2 vs ActivityTestRule
  • ¿Cómo puedo rotar el emulador de Android desde el código de prueba?
  • Prueba de clases sin actividad en Android
  • Método setUp en android.test.AndroidTestCase no es burlado
  • ¿Es una prueba UNIT o una prueba de integración?
  • Prueba de unidad de Android: subclase InstrumentationTestRunner no encontrada
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.