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:
- 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. - Si deseas crear un objeto ficticio para una dependencia de Android, agrega la anotación
@Mock. antes 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 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
}