Cómo compilar pruebas de unidades locales

Una prueba local se ejecuta directamente en tu estación de trabajo, en lugar de una instancia dispositivo o emulador. Utiliza tu máquina virtual Java (JVM) local, en lugar de un dispositivo Android para ejecutar pruebas. Las pruebas locales le permiten evaluar la lógica de tu app más rápido. Sin embargo, no poder interactuar con el El framework de Android crea una limitación en los tipos de pruebas que puedes ejecutar.

Una prueba de unidad verifica el comportamiento de una pequeña sección de código, la unidad en prueba. Para ello, ejecuta el código y verifica el resultado.

Las pruebas de unidades suelen ser simples, pero su configuración puede ser problemática cuando la unidad a prueba no está diseñada teniendo en cuenta la capacidad de prueba:

  • El código que deseas verificar debe ser accesible después de una prueba. Para Por ejemplo, no puedes probar un método privado directamente. En su lugar, se prueba la clase con sus APIs públicas.
  • Para ejecutar pruebas de unidades en aislamiento, las dependencias de la unidad que están en pruebas, deben reemplazarse por componentes que usted controle, como falsificaciones o otros dobles de prueba. Esto es especialmente problemático si tu código depende de el framework de Android.

Para obtener información sobre estrategias comunes de prueba de unidades en Android, lee Qué prueba.

Ubicación de las pruebas locales

De forma predeterminada, los archivos de origen para las pruebas de unidades locales se colocan en module-name/src/test/ Este directorio ya existe cuando creas un nuevo directorio. proyecto con Android Studio.

Cómo agregar dependencias de prueba

También debes configurar las dependencias de prueba para que tu proyecto use el APIs estándar proporcionadas por el framework de pruebas de JUnit.

Para ello, abre el archivo build.gradle del módulo de tu app y especifica lo siguiente bibliotecas como dependencias. Usa la función testImplementation para indicar que aplican al conjunto de orígenes de prueba local y no a la aplicación:

dependencies {
  // Required -- JUnit 4 framework
  testImplementation "junit:junit:$jUnitVersion"
  // Optional -- Robolectric environment
  testImplementation "androidx.test:core:$androidXTestVersion"
  // Optional -- Mockito framework
  testImplementation "org.mockito:mockito-core:$mockitoVersion"
  // Optional -- mockito-kotlin
  testImplementation "org.mockito.kotlin:mockito-kotlin:$mockitoKotlinVersion"
  // Optional -- Mockk framework
  testImplementation "io.mockk:mockk:$mockkVersion"
}

Cómo crear una clase de prueba de unidades local

Escribe la clase de prueba de unidades local como una clase de prueba JUnit 4.

Para ello, crea una clase que contenga uno o más métodos de prueba, generalmente en module-name/src/test/ Un método de prueba comienza con la anotación @Test y contiene el código para ejercitar y verificar un único aspecto del componente que que quieres probar.

En el siguiente ejemplo, se muestra cómo implementar una clase de prueba de unidades local. El el método de prueba emailValidator_correctEmailSimple_returnsTrue()intentos de verificación isValidEmail(),que es un método dentro de la app La función de prueba devolverá El valor true si isValidEmail() también muestra el valor true.

Kotlin

import org.junit.Assert.assertFalse
import org.junit.Assert.assertTrue
import org.junit.Test

class EmailValidatorTest {
  @Test fun emailValidator_CorrectEmailSimple_ReturnsTrue() {
    assertTrue(EmailValidator.isValidEmail("name@email.com"))
  }

}

Java

import org.junit.Test;

import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

class EmailValidatorTest {
  @Test
  public void emailValidator_CorrectEmailSimple_ReturnsTrue() {
    assertTrue(EmailValidator.isValidEmail("name@email.com"));
  }
}

Debes crear pruebas legibles que evalúen si los componentes de tu app muestre los resultados esperados. Te recomendamos usar una biblioteca de aserciones como como junit.Assert, Hamcrest o Truth. El fragmento anterior es un ejemplo de cómo usar junit.Assert

Biblioteca de Android simulable

Cuando ejecutas pruebas de unidades locales, el complemento de Android para Gradle incluye un que contiene todas las APIs del framework de Android, correcta a la versión usada en tu proyecto. La biblioteca contiene todos los métodos públicos y las clases de esas APIs, pero se quitó el código dentro de los métodos. Si corresponde de los métodos, la prueba arroja una excepción.

Esto permite compilar pruebas locales cuando se hace referencia a clases en Android. framework, como Context. Lo más importante es que te permite usar una simulación con clases de Android.

Cómo simular dependencias de Android

Un problema típico es descubrir que una clase usa un recurso de cadenas. Puedes Obtén recursos de cadenas llamando al método getString() en Context . Sin embargo, una prueba local no puede usar Context ni ninguno de sus métodos, ya que pertenecen al framework de Android. Idealmente, la llamada a getString() sería abandonaste la clase, pero esto no siempre es práctico. La solución es crea un modelo o un stub de Context que siempre muestre el mismo valor cuando su Se invoca el método getString().

Con la biblioteca Mockable de Android y los frameworks de simulación, como Mockito o MockK, puedes programar la el comportamiento de las simulaciones de las clases de Android en tus pruebas de unidades.

Para agregar un objeto ficticio a la prueba de unidad local con Mockito, sigue estos pasos: de programación de versiones canary:

  1. Incluye la dependencia de la biblioteca de Mockito en el archivo build.gradle, como que se describe en Configura tu entorno de pruebas.
  2. Al comienzo de la definición de la clase de prueba de unidades, agrega la @RunWith(MockitoJUnitRunner.class). Esta anotación le indica al Mockito para validar que el uso del framework sea correcto y simplifica la inicialización de tus objetos ficticios.
  3. Si deseas crear un objeto ficticio para una dependencia de Android, agrega la anotación @Mock. antes de la declaración del campo.
  4. Para hacer un stub en el comportamiento de la dependencia, puedes especificar una condición y El valor que se muestra cuando se cumple la condición mediante when() y thenReturn() .

En el siguiente ejemplo, se muestra cómo puedes crear una prueba de unidades que use un modelo El objeto Context de Kotlin creado con Mockito-Kotlin

import android.content.Context
import org.junit.Assert.assertEquals
import org.junit.Test
import org.junit.runner.RunWith
import org.mockito.Mock
import org.mockito.junit.MockitoJUnitRunner
import org.mockito.kotlin.doReturn
import org.mockito.kotlin.mock

private const val FAKE_STRING = "HELLO WORLD"

@RunWith(MockitoJUnitRunner::class)
class MockedContextTest {

  @Mock
  private lateinit var mockContext: Context

  @Test
  fun readStringFromContext_LocalizedString() {
    // Given a mocked Context injected into the object under test...
    val mockContext = mock<Context> {
        on { getString(R.string.name_label) } doReturn FAKE_STRING
    }

    val myObjectUnderTest = ClassUnderTest(mockContext)

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

    // ...then the result should be the expected one.
    assertEquals(result, FAKE_STRING)
  }
}

Para obtener más información sobre el uso del framework de Mockito, consulta la API de Mockito. referencia y la clase SharedPreferencesHelperTest en el código de muestra. También prueba el Codelab de pruebas de Android.

Error: "Método… no ficticio"

La biblioteca de Mockable Android arroja una excepción si intentas acceder a cualquiera de sus métodos con el mensaje Error: "Method ... not mocked.

Si las excepciones arrojadas son problemáticas para tus pruebas, puedes cambiar el de modo que, en su lugar, los métodos devuelvan un valor nulo o cero, dependiendo del el tipo de datos que se muestra. Para ello, agrega la siguiente configuración al archivo archivo build.gradle de nivel superior en Groovy:

android {
  ...
  testOptions {
    unitTests.returnDefaultValues = true
  }