¿Existe una manera de escribir una prueba de unidad para una API de destino
Estoy en el proceso de escribir ensayos instrumentados de Android en un área fueron Robolectric sombras personalizadas quedan cortos.
Idealmente, queremos escribir código que sea flexible en todas las versiones del SDK de Android sin embargo estoy en una situación de caso de borde donde necesito escribir una prueba de unidad individual para un método que funciona sólo Marshmallow.
- Necesito Robolectric y Mockito en mi prueba, cada uno propone su propio TestRunner
- Soporte de la clase Robolectric de Android. Cómo tener las referencias de la clase de biblioteca R desde el proyecto de aplicación
- Prueba de unidades de Android con ContentProviders
- Pruebas de ejecución automática antes de la compilación de aplicaciones en Android Studio
- Sugar ORM necesita registros para ser guardado cada vez mientras que la prueba de unidad?
También tengo que escribir una prueba de unidad que sólo funciona para Lollipop y bajo debido a las diferencias en las dependencias del sistema operativo (es decir, java.lang.NoClassDefFoundError)
¿Hay de todos modos puedo hacer esto a través de Junit4-como anotaciones o algo similar a lo que hace Robolectric donde se puede ignorar la ejecución de las pruebas si el SDK no es un buen ajuste?
No quiero escribir código así:
// MarshmallowWidgetTest.java @Test public void testPrintName() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { // ...asserts... } } // LollipopWidgetTest.java @Test public void testPrintName() { if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.LOLLIPOP) { // ...asserts... } }
- Error en la automatización de las pruebas de interfaz de usuario de Android en Jenkins-Server debido a complejas dependencias del proyecto lib de los proyectos principales.
- Gradle - equivalente de test {} bloque de configuración para android
- Prueba de unidades de Android en Eclipse: "Error al iniciar la prueba"
- Combine la cobertura jacoco de androidTest y pruebe
- ¿Cómo obtengo un reporte de cobertura de jacoco usando el complemento Android gradle 0.10.0 o superior?
- `RenamingDelegatingContext` está obsoleto. ¿Cómo probamos SQLite db ahora?
- ¿Por qué Robotium es más lento cuando realiza tareas sencillas de interfaz de usuario en comparación con el código nativo de Android?
- Prueba de la unidad de Android Studio SQLiteDataBase es nula
No estoy muy familiarizado con la unidad de pruebas o Robolectric
, pero porque en el momento de escribir las pruebas de unidad por mí no había soporte para API 23 He utilizado esa configuración:
@RunWith(RobolectricGradleTestRunner.class) @Config(constants = BuildConfig.class, sdk = 21) //this guy public class MainActivityTest { MainActivity_ activity = Robolectric.setupActivity(MainActivity_.class); }
Así como usted ve hay una anotación que puede utilizar para sus clases de prueba.
EDITAR:
Lo siento que me centró sólo en Robolectric
marco de prueba, no problema principal.
Para anotar las pruebas de instrumentación para la API específica que utilizaría:
1. Clase con @Antes de la anotación
Cree una clase con anotación @Before, donde verificará la API de los dispositivos probados. Si está mal, las pruebas fallarían en este método. Utilice fail();
método.
2. Utilice la anotación @SdkSuppress
Indica que una prueba o clase específica requiere un nivel API mínimo para ejecutarse.
Las pruebas se omitirán cuando se ejecuten en plataformas android menos que el nivel especificado.
De: http://developer.android.com/reference/android/support/test/filters/SdkSuppress.html
Por lo tanto, si establecía @SdkSuppress(minSdkVersion=23)
, se ejecutaría sólo en dispositivos Android Marshmallow y si @ @SdkSuppress(minSdkVersion=20)
se ejecutaría sólo en dispositivos API 5.0 superiores.
Lea también: http://www.vogella.com/tutorials/AndroidTesting/article.html
3. Cree su propia anotación como @SdkOnly
Tal vez este artículo sería útil: http://help.testdroid.com/customer/portal/articles/1256803-using-annotations-in-android-instrumentation-tests
4. Crear suites para sus pruebas de instrumentación específicas
Para ello, utilizaría @RunWith()
y Suites.SuiteClasses()
.
Para organizar la ejecución de sus pruebas unitarias instrumentadas, puede agrupar una colección de clases de prueba en una clase de suite de pruebas y ejecutar estas pruebas juntas. Los conjuntos de pruebas pueden anidarse; El conjunto de pruebas puede agrupar otros conjuntos de pruebas y ejecutar todas sus clases de prueba de componentes juntos.
Un paquete de pruebas está contenido en un paquete de prueba, similar al paquete de aplicación principal. Por convención, el nombre del paquete de paquete de prueba normalmente termina con el sufijo .suite (por ejemplo, com.example.android.testing.mysample.suite).
Para crear una suite de pruebas para sus pruebas unitarias, importe las
RunWith
JUnitRunWith
ySuite
. En el conjunto de pruebas, agregue las@RunWith(Suite.class)
y@Suite.SuitClasses()
. En la@Suite.SuiteClasses()
, liste las clases de prueba individuales o las suites de prueba como argumentos.El siguiente ejemplo muestra cómo implementar un conjunto de pruebas denominado
UnitTestSuite
que agrupa y ejecuta las clases de pruebaCalculatorInstrumentationTest
yCalculatorAddParameterizedTest
.import com.example.android.testing.mysample.CalculatorAddParameterizedTest; import com.example.android.testing.mysample.CalculatorInstrumentationTest; import org.junit.runner.RunWith; import org.junit.runners.Suite; // Runs all unit tests. @RunWith(Suite.class) @Suite.SuiteClasses({CalculatorInstrumentationTest.class, CalculatorAddParameterizedTest.class}) public class UnitTestSuite {}
De: http://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html
5. Recursos útiles
- http://www.netmite.com/android/mydroid/development/pdk/docs/instrumentation_testing.html
- https://github.com/googlesamples/android-testing-templates/blob/master/AndroidTestingBlueprint
Espero que ayude
- SQLite obtener todos los datos y pasarlo a un adaptador
- Iniciar la actividad desde la barra de estado crea nueva actividad incluso cuando ya existe