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 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, pruebas 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 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 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 se aplican al conjunto de fuentes 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á verdadero si isValidEmail() también muestra verdadero.
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 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 una biblioteca que contiene todas las APIs del framework de Android, según la versión que se usa 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 se accede a alguno de los métodos, la prueba arroja una excepción.
Esto permite compilar pruebas locales cuando se hace referencia a clases en el framework de Android, como Context. Lo más importante es que te permite usar una simulación
con clases de Android.
Cómo generar simulaciones de dependencias de Android
Un problema típico es descubrir que una clase usa un recurso de cadena. Puedes obtener recursos de cadenas 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. Idealmente, la llamada a getString() se quitaría de 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 de Android simulada y los frameworks de simulación, 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 la prueba de unidad local con Mockito, sigue este modelo de programación:
- Incluye la dependencia de la biblioteca de Mockito en el archivo
build.gradle, como que se describe en Configura tu entorno de pruebas. - 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. - Para crear un objeto ficticio para una dependencia de Android, agrega la anotación
@Mockantes de la declaración del campo. - 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()ythenReturn().
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 referencia de la API de Mockito 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 Android simulada 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 en el archivo build.gradle de nivel superior de tu proyecto en Groovy:
android {
...
testOptions {
unitTests.returnDefaultValues = true
}