Hace poco os compartí un proyecto Android en Github. Se trata de una aplicación para leer películas desde un web service. Aquí os dejo de nuevo el enlace https://github.com/3pies/movies

A partir de ahora empezaré a testearla poco a poco. Hoy empezaremos a preparar nuestra app para testing.

Para testear nuestras clases, lo habitual es crear clases mock que nos ayuden a centrarnos en la clase que estamos testando. Estos mocks se comportarán tal como nosotros queremos para que el resultado del test sea siempre predecible.

Vamos al lío. Lo primero que debemos hacer es añadir las librerías necesarias al proyecto. Para ello, abrimos el archivo build.gradle de nuestra aplicación y añadimos las dependencias necesarias.

Por un lado debemos añadir junit a nuestro proyecto, para tener las funcionalidades básicas de test.

testImplementation 'junit:junit:4.13.2'

Y además la librería Mockito. Fijaros que lo hacemos con «testImplementation», de este modo, las librerías solo se cargarán cuando ejecutemos los test unitarios.

testImplementation "org.mockito:mockito-core:4.6.1"
testImplementation "org.mockito.kotlin:mockito-kotlin:4.0.0"

Sincronizamos y podemos empezar nuestros tests. Pero, no os vayáis todavía, que queda una sorpresa.

Voy a crear un ejemplo de clase para probar. En el repositorio lo podréis encontrar en el archivo Playground.kt, el cual usaré para diferentes pruebas.

class Bar() {
    fun sayHello(): String { return "hello" }
}

class Foo constructor(private var bar: Bar) {
    fun saySomething(): String {
        return bar.sayHello()
    }
}

Ok, tenemos una clase Foo que usa Bar para devolver un texto. Desde Foo el método saySomething llama al método sayHello de bar. Creemos un test para verificar que esto siempre se cumple.

Vamos a crear nuestro primer test unitario sobre la clase Foo. Para ello, con la vista Android seleccionada, vamos a la carpeta de test. Es la que tiene el nombre de nuestro namespace y entre paréntesis aparece test.

Creamos otro archivo para pruebas, le llamaré PlaygroundTest.kt

Creamos nuestra clase de Test y definimos un mock para Bar. Nuestra clase la marcamos con una anotation que indicará que se ejecuta con Junit, y para nuestro mock hacemos uso de Mockito.mock. Simple.

@RunWith(JUnit4::class)
class FooTest {

    private val bar = Mockito.mock(Bar::class.java)
    
}

Y dentro de esta clase debemos crear nuestro primer test. Veámoslo.

@Test
fun `Test say something`() {
    Mockito.`when`(bar.sayHello()).thenReturn("goodbye")

    val foo = Foo(bar)

    val result = foo.saySomething()

    verify(bar, times(1)).sayHello()
    assertThat(result, CoreMatchers.`is`("goodbye"))
}

Lo primero que hacemos es definir como se comportará el mock de Bar cuando llamemos a «sayHello». Seguimos instanciando un objeto Foo y llamando el método a testear: saySomething. Y por último, verificamos que se ejecuta sayHello y el resultado es el que se espera. Fácil, no? Pues no.

Ejecutad este test y veréis que da error. Aquí es donde quería llegar. El problema es que nuestra clase Bar y el método sayHello necesitan que se declaren como open.

Podéis probar a marcar como open Bar y su método y volver a ejecutar, veréis que ahora se ejecuta correctamente.

open class Bar() {
    open fun sayHello(): String { return "hello" }
}

Ya está, se acabó, no? Pues no.

Si ya es público, ¿porque necesito abrirlo aún más? Deberíamos dar a las clases el nivel de privacidad más restrictivo posible e ir abriendo solo según se necesite. En este caso, marcar como open clase y método no es la solución ideal, ya que a partir de ahora todas nuestras clases y métodos debemos marcarlos así para poder testear. 🙁

Si al menos tuviéramos algo que nos marcase nuestra clase como open solo cuando ejecutamos los tests… Ehhh, que si que existe eso.

Simplemente haced esto, dentro de la carpeta app de nuestro proyecto creamos carpeta resources, y dentro de esta otra carpeta que llamamos mockito-extensions. En esta carpeta creamos un archivo y le llamamos org.mockito.plugins.MockMaker. En este archivo añadimos la siguiente línea:

mock-maker-inline

Ahora eliminamos la instrucción open de nuestra clase Bar, y listo. Probar a ejecutar el test de nuevo. Ahora funciona correctamente, y nuestras clases y métodos podrán tener la visibilidad que le corresponda.

Creedme, esto puede llegar a ser un quebradero de cabeza para quien se inicia a testear una app. Probadlo y me contáis que tal os fue.