Divida las pruebas de Android en módulos | Compartir código de prueba en Android

Todos hemos escuchado acerca de cómo la modularización de su aplicación de Android en diferentes módulos es beneficiosa tanto para el mantenimiento del código como para el rendimiento de la compilación. Por lo tanto, en este blog, hablaremos sobre cómo esto también se puede hacer para sus pruebas de instrumentación. Tanto un módulo de biblioteca de Android como un módulo de aplicación pueden tener un conjunto de fuentes de AndroidTest donde puede escribir pruebas que también se ejecutan en un dispositivo como un conjunto de fuentes de prueba (unitTest) que se ejecuta localmente en la JVM. Es posible que tenga la tentación de escribir todas sus pruebas en la JVM y usar marcos como Robolectric o simulacros/stubs donde necesite algunas dependencias del marco de trabajo de Android, ya que son más rápidos y fáciles de ejecutar. Pero en su aplicación, es posible que tenga una biblioteca nativa que no esté compilada para su máquina JVM local, o desee escribir pruebas que prueben la aplicación en un dispositivo real. Este es el caso cuando es necesario escribir pruebas dentro del conjunto de fuentes androidTest. Tanto los desarrolladores como los QA de su equipo pueden automatizar los diversos escenarios en su aplicación al escribir pruebas dentro del conjunto de fuentes de AndroidTest. El conjunto de fuentes androidTest en un módulo de aplicación a menudo puede crecer drásticamente con cientos o incluso miles de pruebas. Puede ser una combinación de pruebas de captura de pantalla, pruebas de red, pruebas de flujo de trabajo de extremo a extremo, pruebas de rendimiento, etc. Solo generar un APK de prueba de Android para una nueva prueba puede llevar más tiempo que su APK normal. Si también usa complementos como Hilt o Dagger, esto puede empeorar aún más. También puede resultar difícil decidir qué pruebas funcionarían localmente sin factores externos, o qué pruebas dependen de un dispositivo o dependencia específicos. Es posible que incluso deba introducir nuevas anotaciones para administrarlas de manera efectiva.El conjunto de fuentes androidTest tiene muchas pruebas diferentes. Este es el punto donde el código androidTest se vuelve difícil de mantener. Para hacer que el código de prueba sea más fácil de mantener, puede dividir su código de prueba de Android en diferentes módulos de Gradle. Una forma es crear módulos de biblioteca separados en los que incluiría su aplicación como un módulo dependiente. Pero no es tan fácil, y es posible que termine encontrando extraños problemas de fusión de manifiestos. Además, crearía módulos de biblioteca completamente nuevos, donde no necesita el código fuente principal o de prueba (unitTest). Aquí es donde los módulos de prueba de Android vienen al rescate. Estos son módulos especiales que contienen solo pruebas de instrumentación y le permiten incluir la aplicación y otros módulos de biblioteca como dependencias.Varios módulos solo de prueba que dependen del módulo de su aplicación Para crear un módulo solo de prueba de Android, debe realizar los siguientes pasos:

  1. Cree un nuevo módulo en su proyecto y use el complemento com.android.test en el archivo build.gradle de este módulo:

complementos { // Esto es puramente un módulo de prueba. // Todas las pruebas internas se ejecutarán como Android Instrumentation Tests.id ‘com.android.test’ }

Nota: Para crear un nuevo módulo, puede usar las plantillas de Android Studio y comenzar con un módulo de biblioteca como punto de partida y luego reemplazar com.android.library con el complemento com.android.test en su archivo build.gradle

2. Especifique el proyecto que desea probar con Android. { // Aquí estoy apuntando al módulo de la aplicación. targetProjectPath ‘:app’….// Si el módulo de su aplicación tiene sabores diferentes, debe declarar lo mismo aquí.}3. En su bloque de dependencia, defina las diversas dependencias de prueba y proyecto como dependencias de implementación normales .5 ‘implementación’ androidx.test.espresso:espresso-core:3.5 .1’ImplementationProject(‘:app’)}4. Cree su primera prueba como esta en su módulo de solo prueba. Todo el código de prueba debe estar en el conjunto de fuentes principal en lugar del conjunto de fuentes de AndroidTest. class ExampleAppInstrumentedTest {@get:Ruleval activityScenarioRule = ActivityScenarioRule(MainActivity::class.java)@ Testfun testAppModuleActivity() {Espresso.onView(ViewMatchers.withId(com.example.testonlymodule.R.id.main_activity_view)).check(ViewAssertions. matches(ViewMatchers.isDisplayed()))}} Puede ejecutar todas sus pruebas de instrumentación en dicho módulo usando un comando de Gradle como este. (Reemplace moduleName con el nombre real del módulo que creó)./gradlew :{moduleName}:connectedDebugAndroidTest¡Eso es todo! Así de fácil es configurar un módulo solo de prueba para sus pruebas de instrumentación Consulte el repositorio: https://github.com/shubhamgarg1/ TestOnlyModule Puede usar Jacoco con estos módulos para generar la cobertura de código de su aplicación. Incluso puede ejecutar estas pruebas usando emuladores sin periféricos con dispositivos administrados por Gradle (versión mínima de AGP: 7.3.1). Para compartir código entre sus diferentes módulos de prueba, puede crear un módulo de prueba común que todos sus módulos de prueba puedan incluir. El módulo de prueba compartido necesitaría ser un módulo de biblioteca, ya que Android actualmente no le permite envolver módulos de solo prueba uno dentro de otro. El mismo concepto se usa cuando desea compartir código entre su prueba unitaria y los conjuntos de fuentes de prueba de Android. Anteriormente, esto era posible al incluir los paquetes comunes en ambos conjuntos de fuentes. Sin embargo, con Android Studio Chipmunk, esto ya no es posible. Supongamos que hay algunas utilidades comunes entre la prueba de red y los módulos de prueba de rendimiento. Puede crear un módulo Share Test Utility como el siguiente:Esta es una descripción general de cómo puede organizar su código de prueba con el complemento com.android.test y cómo puede ayudar a que su código de prueba sea más fácil de mantener y escalable. Con este tipo de división, puede decidir ejecutar algunos módulos de prueba después de cada confirmación, algunos módulos de prueba una vez al día, etc.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.