Prueba de aplicaciones de Android. Este ensayo tiene como objetivo discutir algunos de los principales… | de Kayvan Kaseb | Desarrollo de software | Noviembre de 2020

La imagen es proporcionada por Unsplash

Como sabe, probar su aplicación de Android juega un papel vital en el proceso de desarrollo. Después de probar su aplicación, es posible que pueda verificar la corrección, el comportamiento funcional y la usabilidad de su aplicación antes del proceso de lanzamiento. Hay varias herramientas y métodos en las pruebas de Android. Sin embargo, hoy en día, Google ha anunciado AndroidX Test, que trae algunas características y capacidades avanzadas de esta manera. Este ensayo tiene como objetivo discutir algunos conceptos e ideas importantes en las pruebas de Android durante los últimos años.

Intruducción y resumen general

En el desarrollo de software existe el concepto de pirámide de prueba. Consta de tres niveles: unidad, integración y pruebas de extremo a extremo. A medida que subes la pirámide, has comido ganando lealtad, pero también aumenta el tiempo de ejecución y el esfuerzo para mantener y depurar.

The Testing Pyramid, la imagen es proporcionada por Google Docs

Además, cada vez es más difícil mantener y depurar este tipo de pruebas. Sin embargo, al igual que en una banda de rock, donde necesitas una combinación perfecta de músicos para crear esa gran pista, cada capa de la pirámide es igualmente significativa. Está aprovechando los beneficios de una capa para compensar las compensaciones en otras para producir un entorno de prueba automatizado integral. A pesar de que la proporción de pruebas para cada categoría puede basarse en los casos de uso de su aplicación de Android, Google ha recomendado una división 70/20/10 como una pauta general de sonido. Actualmente, aunque las reglas de estas pirámides siguen siendo válidas, algunas de las características únicas del desarrollo de Android han introducido algunas dificultades en el camino.

Básicamente, Prueba de unidad se ejecutará en la estación de trabajo local debido a la necesidad de ser rápido. Además, Integración es De un extremo al otro Las pruebas tienden a ejecutarse en un dispositivo real o virtual debido a su necesidad de ejecutarse en un entorno muy fiel. Como resultado, se desarrollaron herramientas separadas en cada capa de la pirámide. Roboeléctrico es Mockito para pruebas unitarias externas al dispositivo. Café exprés y el Prueba de AndroidX diseñaron para esas pruebas en el dispositivo.

Las siguientes secciones de este artículo considerarán estos conceptos.

Considerando algunas herramientas para realizar pruebas

  1. DATOS: condición de instalación

2. CUÁNDO: se toman medidas

3. ENTONCES: una afirmación es verdadera

Ahora, las siguientes secciones comparan brevemente los distintos estilos de Mockito, Robolectric y Espresso.

Mockito

Burlarse es una herramienta realmente poderosa, pero a menudo se usa en exceso y en algunas situaciones. Burlarse de sus propias clases está bien para su uso, pero si bien burlarse del marco de Android puede parecer una idea apropiada al principio, pronto puede conducir a un camino de problemas difíciles. Varias clases de Android han sido con estado o tienen contratos complejos y estos son ciertamente difíciles, o incluso imposibles, de cumplir con simulaciones.

Inicialmente, el marco de simulación de Mockito para Java (versión 1.9.5 y superior) proporciona compatibilidad con las pruebas unitarias de Android. Con Mockito, es posible que pueda configurar objetos ficticios para que devuelvan un valor específico cuando se invocan. En general, si tiene dependencias mínimas de Android y requiere que pruebe interacciones específicas entre un componente y su dependencia dentro de su aplicación de Android, debe usar un marco de simulación como Mockito para incorporar dependencias externas en su código. Por lo tanto, puede probar fácilmente cómo su componente interactúa con la adicción de la manera esperada. Al intercambiar dependencias de Android por objetos ficticios, puede aislar su prueba unitaria del resto del sistema Android cuando se invocan los métodos correctos en esas dependencias. Por ejemplo, el siguiente código demuestra cómo crear una prueba unitaria que usa un simulacro Context objeto:

import android.content.Context
import com.google.common.truth.Truth.assertThat
import org.junit.Test
import org.junit.runner.RunWith
import org.mockito.Mock
import org.mockito.Mockito.`when`
import org.mockito.junit.MockitoJUnitRunner

private const val FAKE_STRING = "HELLO WORLD"

@RunWith(MockitoJUnitRunner::class)
class UnitTestSample {

@Mock
private lateinit var mockContext: Context

@Test
fun readStringFromContext_LocalizedString() {
// given a mocked Context injected into the object.
`when`(mockContext.getString(R.string.hello_word))
.thenReturn(FAKE_STRING)
val myObjectUnderTest = ClassUnderTest(mockContext)

// when the string is returned from the object.
val result: String = myObjectUnderTest.getHelloWorldString()

// then the result should be the expected one.
assertThat(result, `is`(FAKE_STRING))
}
}

Roboeléctrico

Robolectric es el popular marco de pruebas de código abierto. Le permite seguir las mejores prácticas simuladas, ya que puede usar objetos reales de Android en sus pruebas en lugar de programar su propio comportamiento de stubbing en cada prueba. Funciona en su host local, lo que significa que es muy rápido e ideal para pruebas unitarias. Robolectric tiende a realizar pruebas que se pueden leer mucho más limpias. En otras palabras, Robolectric simula el tiempo de ejecución para Android 4.1 (nivel de API 16) o superior y admite falsificaciones gestionadas por la comunidad llamadas oscuridad. Esta función le permite probar el código dependiente del marco sin la necesidad de utilizar un emulador u objetos ficticios. Robolectric ofrece los siguientes aspectos de la plataforma Android: ciclos de vida de los componentes, bucles de eventos y todos los recursos. Por ejemplo, tiene un diseño de actividad que representa una pantalla de bienvenida (una actividad que incluye un botón de inicio de sesión) y queremos escribir una prueba que afirme que cuando un usuario hace clic en un botón, la aplicación inicia la actividad de inicio de sesión. Para probar este caso, es posible que podamos verificar que cuando un usuario hace clic en el botón «Iniciar sesión», iniciamos la intención correcta. Dado que Robolectric es un marco de prueba unitario, LoginActivity no se iniciará; sin embargo, podemos verificar que WelcomeActivity haya activado la intención correcta.

@RunWith(RobolectricTestRunner.class)
public class WelcomeActivityTest {
@Test
public void clickingLogin_shouldStartLoginActivity() {
WelcomeActivity activity = Robolectric.setupActivity(WelcomeActivity.class);
activity.findViewById(R.id.login).performClick();
Intent expectedIntent = new Intent(activity, LoginActivity.class);
Intent actual = shadowOf(RuntimeEnvironment.application).getNextStartedActivity();
assertEquals(expectedIntent.getComponent(), actual.getComponent());
}
}

Café exprés

Espresso es un marco de prueba de IU y se ejecuta en un dispositivo real o virtual. Le proporciona un entorno verdaderamente realista. La compensación aquí es una velocidad de ejecución mucho más lenta. Estás compilando el APK completo, implementándolo en el dispositivo y creando una instancia de la ejecución de prueba. Esperar los resultados y luego recopilarlos en su estación de trabajo local. Todo esto se suma a valiosos ciclos de desarrollo. El siguiente código muestra un ejemplo de una prueba de Espresso:

@Test
fun greeterSaysHello() {
onView(withId(R.id.name_field)).perform(typeText("Steve"))
onView(withId(R.id.greet_button)).perform(click())
onView(withText("Hello Steve!")).check(matches(isDisplayed()))
}

Espresso verifica claramente las expectativas, interacciones y afirmaciones sin la distracción de los códigos estándar, la infraestructura personalizada o los detalles desordenados del edificio que se interponen en el camino. Por ejemplo, JUnit4 prueba utilizando las siguientes reglas:

@RunWith(AndroidJUnit4::class)
@LargeTest
class HelloWorldEspressoTest {

@get:Rule
val activityRule = ActivityScenarioRule(MainActivity::class.java)

@Test fun listGoesOverTheFold() {
onView(withText("Hello world!")).check(matches(isDisplayed()))
}
}

Intenta escribir crisis

Prueba de AndroidX

  1. Implementar afirmaciones más legibles usando Verdad: El equipo de Guava ofrece una biblioteca de afirmaciones fluida llamada Truth. En general, puede utilizar Verdad para indicar que un objeto en particular tiene una propiedad específica usando oraciones que contienen las condiciones que está probando. Por ejemplo:

assertThat(object).doesNotHaveFlags(FLAGS) assertThat(intent).hasData(URI)

2. Escribir pruebas de IU: Para escribir pruebas de IU de manera eficiente, debe usar Espresso, que le permite ubicar e interactuar mediante programación con elementos de IU en su aplicación de Android de una manera segura para subprocesos.

3. Ejecución de pruebas de interfaz de usuario: la AndroidJUnitRunner class muestra un corredor de prueba JUnit basado en instrumentación que le permite ejecutar clases de prueba de estilo JUnit 3 o JUnit 4 en dispositivos Android. Además, para aumentar la confiabilidad de estas pruebas, puede usar Android Test Orchestrator que ejecuta cada prueba de IU en su propia caja de arena de instrumentación.

4. Interactuar con elementos visibles: La API de UI Automator le permite interactuar con elementos visibles en un dispositivo en lugar de la actividad o fragmento, que se ha enfocado.

5. Usar controles de accesibilidad para validar la usabilidad: Para ayudar a validar la accesibilidad de su aplicación de Android, la biblioteca de pruebas de Android ofrece varias funciones integradas usando Roboeléctrico es Café exprés.

6. Seguimiento de sus actividades y fragmentos: puedes usar el ActivityScenario es FragmentScenario clases para probar cómo las actividades y los fragmentos de tu aplicación de Android responden a interrupciones en todo el sistema y cambios de configuración en condiciones del mundo real.

7. Gestionar los ciclos de vida de los servicios clave.

8. Evaluación de todas las variantes de comportamiento que difieren según la versión del SDK.

En conclusión

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *