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

Question

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

ACTUALIZACIÓN: Ahora hay una herramienta (Junit4Android) para obtener apoyo para Junit4 en Android. Es un poco complicado, pero debería funcionar.

Para lograr el equivalente de @BeforeClass, he estado usando una variable estática e inicializándola 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 manera de detectar cuando la última prueba se ha quedado

public class MyTest extends ActivityInstrumentationTestCase2<MainActivity> { 
    private static boolean firstRun = true; 

    @Override 
    protected void setUp() { 
     if(firstRun) { 
      firstRun = false; 
      setUpDatabaseFixture(); 
     } 
    } 
    ... 
} 

Answer 1

Desde el junit website (ya que creo que no hay garantía del orden de ejecución de la prueba.):

envuelto el método setUp y tearDown en el conjunto. Esto es para el caso si desea ejecutar un solo caso de prueba 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 montaje y desmontaje de todo el caso de prueba, hacer una suite y añadir TestClass a ella y pasar el objeto suite de en TestSetup constructor.But Creo que hay no es mucho uso para esto, y de alguna manera está violando la filosofía JUnit.

Answer 2

Recientemente, estaba buscando una solución similar también. Afortunadamente, en mi caso después de que la JVM sale después de que se ejecuta la última prueba. 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.

Answer 3

Sugeriría evitar este tipo de dependencias donde necesita saber el orden en que se ejecutan las pruebas. Si todo lo que necesita es restaurar una base de datos real que fue reemplazada por setUpDatabaseFixture(), probablemente su solución provenga del uso de un RenamingDelegatingContext. De todos modos, si no se puede evitar saber cuándo se realizó la última prueba, puede utilizar 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 ***"); 
    } 
} 

Answer 4

No es éste (que trata con elegancia con los datos, por lo que no tiene que preocuparse acerca de la restauración it) ¿qué testing with mock objects son para? Android supports mocking.

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

---

En mi experiencia, y desde this blog post, cuando las pruebas Android se convierten en una suite y corren por el InstrumentationTestRunner - ActivityInstrumentationTestCase2 es una extensión de ActivityTestCase que es un extendsion de InstrumentationTestCase - se ordenan alfabéticamente usando android.test.suitebuilder.TestGrouping.SORT_BY_FULLY_QUALIFIED_NAME, por lo que puede restaurar su BD con un método que es el mínimo en el alfabeto de los nombres de las pruebas, como:

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

---

Nota:

Hay que prestar atención a las pruebas heredados, ya que no se ejecutarán en este orden. La solución es anular todas las pruebas heredadas y simplemente llamar a super() desde la anulación. Esto hará que una vez más todo se ejecute alfabéticamente.

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(); } 
}