Cómo compilar pruebas de unidades locales

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

Una prueba de unit verifica el comportamiento de una pequeña sección de código, la unidad que se está probando. Para ello, ejecuta el código y verifica el resultado.

Las pruebas de unidades suelen ser simples, pero su configuración puede causar problemas cuando la unidad que se está probando no se diseñó teniendo en cuenta la capacidad de prueba:

  • El código que deseas verificar debe ser accesible desde una prueba. Por ejemplo, no puedes probar un método privado de forma directa. En su lugar, debes probar la clase con sus API públicas.
  • Para ejecutar pruebas de unidades en aislamiento, las dependencias de la unidad en prueba deben reemplazarse por componentes que controles, como falsificaciones u otros dobles de prueba. Esto resulta particularmente problemático si tu código depende del framework de Android.

Para obtener más información sobre las estrategias comunes de prueba de unidades en Android, consulta Qué probar.

Ubicación de 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 proyecto nuevo con Android Studio.

Cómo agregar dependencias de prueba

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

Para ello, abre el archivo build.gradle del módulo de tu app y especifica las siguientes bibliotecas como dependencias. Usa la función testImplementation para indicar que se 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, por lo general, en module-name/src/test/. Un método de prueba comienza con la anotación @Test y contiene el código para ejecutar y verificar un solo aspecto del componente que quieres probar.

En el siguiente ejemplo, se muestra cómo implementar una clase de prueba de unidad local. El método de prueba emailValidator_correctEmailSimple_returnsTrue()intenta verificar isValidEmail(),que es un método dentro de la app. La función de prueba mostrará true si isValidEmail() también lo hace.

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 la app muestran los resultados esperados. Te recomendamos que uses una biblioteca de aserciones 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 una biblioteca que contiene todas las APIs del framework de Android, correctas a la versión que se usó en tu proyecto. La biblioteca contiene todos los métodos y las clases públicos de esas APIs, pero se quitó el código dentro de los métodos. Si se accede a alguno de los métodos, la prueba arrojará una excepción.

Esto permite que se compilen pruebas locales cuando se hace referencia a clases en el framework de Android, como Context. Sobre todo, te permite usar un framework de simulación con clases de Android.

Simulación de dependencias de Android

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

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

Para agregar un objeto ficticio a tu prueba de unidad local con Mockito, sigue este modelo de programación:

  1. Incluye la dependencia de la biblioteca de Mockito en el archivo build.gradle, como se describe en Cómo configurar el entorno de pruebas.
  2. Al comienzo de la definición de la clase de prueba de unidades, agrega la anotación @RunWith(MockitoJUnitRunner.class). Esa anotación le indica al ejecutor de pruebas de Mockito que valide que tu 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 indicar el comportamiento de la dependencia, puedes especificar una condición y un valor que se muestre cuando se cumpla con la condición mediante los métodos when() y thenReturn().

En el siguiente ejemplo, se muestra cómo puedes crear una prueba de unidades que use un objeto Context ficticio en 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 referencia de la API de Mockito y la clase SharedPreferencesHelperTest en el código de muestra. También prueba el Android Testing Codelab.

Error: "Método… no ficticio"

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

Si las excepciones generadas son problemáticas para las pruebas, puedes cambiar el comportamiento para que los métodos muestren un valor nulo o cero, según el tipo de datos que se muestra. Para ello, agrega la siguiente configuración al archivo build.gradle de nivel superior de tu proyecto en Groovy:

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