2011-07-21 13 views
8

¿Hay un control en tiempo de ejecución para que una aplicación descubra si se ejecuta como parte de una prueba de instrumentación?¿Es posible averiguar si una aplicación de Android se ejecuta como parte de una prueba de instrumentación?

Antecedentes: nuestra aplicación realiza una sincronización de base de datos al iniciar. Pero eso debería suceder solo cuando se inicia regularmente. Interfiere especialmente con las pruebas de instrumentación que prueban la sincronización db. No es sorprendente.

Y con todas las otras pruebas es solo un desperdicio de ciclos de CPU.

+0

¿ha encontrado alguna solución para esto? – Piotr

Respuesta

2

Si está utilizando ActivityUnitTestCase, puede establecer un objeto Aplicación personalizado con setApplication y tener un indicador allí para activar o desactivar la sincronización de la base de datos. Hay un ejemplo del uso de un objeto de aplicación personalizada en mi blog:

http://www.paulbutcher.com/2011/03/mock-objects-on-android-with-borachio-part-3/

+0

Interesante. Ya tengo una aplicación personalizada donde podría fácilmente una bandera de prueba de instrumentación. Lo intentaré mañana. – Martin

+0

Algo más en lo que pensar: podría usar RoboGuice http://code.google.com/p/roboguice/ para insertar una versión de solo prueba de su código de sincronización db según corresponda (esto es lo que hacemos en nuestro código de prueba)) Hay una descripción de nuestra configuración aquí: http://www.swiftkey.net/blog/?p=496 –

+0

Parece que solo los casos de prueba de actividad y servicio tienen un método 'setApplication' y el simple' AndroidTestCase' no lo hará. Pero luego parecen funcionar bien de todos modos. De todos modos parece el único abierto. thnaks. – Martin

5

ya que el nivel de API 11, el método ActivityManager.isRunningInTestHarness() está disponible. Esto podría hacer lo que quieras.

+8

Me está devolviendo las pruebas, ya sea que esté ejecutando las pruebas o la configuración de la aplicación – Piotr

+0

Este método básicamente solo lo usan las aplicaciones del sistema cuando necesitan averiguar si correr en algún arnés de prueba de plataforma. Vea mi error aquí: http://b.android.com/191171 –

1

Puede pasar un intento extra a su actividad indicando que está bajo prueba.

1) En la prueba, pase "TestMode" adicional a su actividad:

2) En su actividad, la verificación de TestMode:

Bundle extras = getIntent().getExtras(); 
if (extras != null && extras.getBoolean("testMode")) { 
    // disable your database sync 
} 
+0

Utilizo este método para algunas pruebas de código heredado. Sin embargo, señalaría que su código de producción generalmente no debería manejar las pruebas de ninguna manera. –

3

Una solución mucho más simple es cheque por una clase que solo estaría presente en un classpath de prueba, funciona con JUnit 4 (a diferencia de la solución que usa ActivityUnitTestCase) y no requiere enviar intenciones personalizadas a sus Actividades/Servicios (lo que podría no ser posible en algunos casos)

private boolean isTesting() { 
    try { 
     Class.forName("com.company.SomeTestClass"); 
     return true; 
    } catch (ClassNotFoundException e) { 
     return false; 
    } 
} 
0

Este trabajo para mí, porque no hay ningún dispositivo real se está ejecutando

public static boolean isUnitTest() { 
    return Build.BRAND.startsWith(Build.UNKNOWN) && Build.DEVICE.startsWith(Build.UNKNOWN) && Build.DEVICE.startsWith(Build.UNKNOWN) && Build.PRODUCT.startsWith(Build.UNKNOWN); 
} 
+0

No estoy seguro de que deba probar dos veces para DEVICE. En mi máquina de prueba con AS 2.3.3 y JDK incorporado, BRAND, DEVICE y PRODUCT son nulos, la prueba se convierte en: return (Build.BRAND == null || Build.BRAND.startsWith (Build.UNKNOWN)) && (Build .DEVICE == null || Build.DEVICE.startsWith (Build.UNKNOWN)) && (Build.PRODUCT == null || Build.PRODUCT.startsWith (Build.UNKNOWN)); – Timores

Cuestiones relacionadas