¿Cómo puedo obtener @BeforeClass y @AfterClass equivalente en Junit3?

Quiero hacer una copia de seguridad de la base de datos de mi aplicación antes de reemplazarla por el dispositivo de prueba. Estoy obligado a usar Junit3 debido a las limitaciones de Android, y quiero implementar el comportamiento equivalente de @BeforeClass a @AfterClass.

UPDATE: Ahora hay una herramienta ( Junit4Android ) para obtener soporte para Junit4 en Android. Es un poco de un kludge pero debe trabajar.

Para lograr el equivalente @BeforeClass, había estado utilizando una variable estática e inicializarla durante la primera ejecución como esta, pero necesito poder restaurar la base de datos después de ejecutar todas las pruebas. No puedo pensar en una forma de detectar cuándo se ha ejecutado la última prueba (ya que creo que no hay garantía en el orden de ejecución de la prueba).

public class MyTest extends ActivityInstrumentationTestCase2<MainActivity> { private static boolean firstRun = true; @Override protected void setUp() { if(firstRun) { firstRun = false; setUpDatabaseFixture(); } } ... } 

Desde el sitio web junit :

Envolvió el método setUp y tearDown en la suite. Esto es para el caso si desea ejecutar un único testcase de YourTestClass.

 public static Test suite() { return new TestSetup(new TestSuite(YourTestClass.class)) { protected void setUp() throws Exception { System.out.println(" Global setUp "); } protected void tearDown() throws Exception { System.out.println(" Global tearDown "); } }; } 

Si desea ejecutar sólo un setUp y tearDown para todos los testcase, haga una suite y agregue testClass a ella y pase el objeto suite en el constructor TestSetup. Pero creo que no hay mucho uso para esto, y de alguna manera es Violando la filosofía de JUnit.

Recientemente, yo estaba buscando una solución similar también. Afortunadamente, en mi caso después de las salidas JVM después de la última prueba se ejecuta. Así que pude lograr esto agregando un gancho de cierre de JVM.

 // Restore database after running all tests Runtime.getRuntime().addShutdownHook(new Thread() { public void run() { restoreDatabase(); } }); 

espero que esto ayude.

¿No es esto (tratar elegantemente con los datos, por lo que no tiene que preocuparse por su restauración) lo que las pruebas con objetos simulados son para? Android es compatible con burlas .

Le hago una pregunta, ya que nunca me he burlado de Android.


En mis experiencias, y desde esta entrada del blog , cuando las pruebas de Android se convierten en una suite y ejecutadas por el InstrumentationTestRunnerActivityInstrumentationTestCase2 es una extensión de ActivityTestCase que es una extensión de InstrumentationTestCase – se ordenan alfabéticamente usando android.test.suitebuilder.TestGrouping.SORT_BY_FULLY_QUALIFIED_NAME , por lo que sólo puede restaurar DB con un método que es el lowes en el alfabeto de los nombres de prueba, como:

 // underscore is low in the alphabet public void test___________Restore() { ... } 

Nota:

Tienes que prestar atención a las pruebas heredadas, ya que no se ejecutarán en este orden. La solución es anular todas las pruebas heredadas y simplemente llamar a super () de la anulación. Una vez más, todo se ejecutará en orden alfabético.

Ejemplo:

 // Reusable class w only one time setup and finish. // Abstract so it is not run by itself. public abstract class Parent extends InstrumentationTestCase { @LargeTest public void test_001_Setup() { ... } @LargeTest public void test_____Finish() { ... } } /*-----------------------------------------------------------------------------*/ // These will run in order shown due to naming. // Inherited tests would not run in order shown w/o the use of overrides & supers public class Child extends Parent { @LargeTest public void test_001_Setup() { super.test_001_Setup(); } @SmallTest public void test_002_MainViewIsVisible() { ... } ... @LargeTest public void test_____Finish() { super.test_____Finish(); } } 

Yo sugeriría evitar este tipo de dependencias donde usted necesita saber el orden en que se ejecutan las pruebas. Si todo lo que necesitas es restaurar una base de datos real que fue reemplazada por setUpDatabaseFixture() probablemente la solución viene del uso de un RenamingDelegatingContext . De todos modos, si no puedes evitar saber cuándo se ejecutó la última prueba, puedes usar algo como esto:

 ... private static final int NUMBER_OF_TESTS = 5; // count your tests here private static int sTestsRun = 0; ... protected void tearDown() throws Exception { super.tearDown(); sTestsRun += countTestCases(); if ( sTestsRun >= NUMBER_OF_TESTS ) { android.util.Log.d("tearDow", "*** Last test run ***"); } } 
  • ¿Por qué JUnit 4 en Android no funciona?
  • Robolectric + Eclipse ¿No encuentra recursos?
  • Prueba de clases sin actividad en Android
  • Prueba de unidad MVP usando mockito con los oyentes de eventos
  • RxJava file.createNewFile () devuelve siempre TRUE
  • ActivityInstrumentationTestCase2 vs ActivityTestRule
  • InitializationError para AndroidJunit4
  • Cómo ejecutar swipe con appium en Java para la aplicación nativa de Android
  • Anotación @UiThreadTest produce "java.lang.Exception: No se pueden ejecutar métodos"
  • Error: Error de ejecución para la tarea ': app: transformClassesWithMultidexlistForDebugAndroidTest'
  • Android Studio Error JUNIT4! JUnit versión 3.8 o posterior esperado:
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.