No es test de UI todo lo que reluce

El desarrollo de tests est谩 a la orden del d铆a como pr谩ctica habitual para asegurar la calidad del software. No solo ingenieros QA, sino tambi茅n ingenieros de software, tienen como una de sus tareas el a帽adir tests a sus desarrollos. La idea principal es evitar errores y situaciones regresivas, as铆 como aprovechar las bondades de los sistemas de integraci贸n cont铆nua para realizar su ejecuci贸n de manera autom谩tica.

Bien es sabido que existen m煤ltiples tipos de tests, y cada equipo de desarrollo/QA se puede hacer cargo de determinados tipos. Esto algo a determinar dependiendo de las caracter铆sticas y aptitudes que existan dentro del equipo. Siempre me llam贸 la atenci贸n que la l铆nea conceptual que separa determinados tipos de tests es muy fina, y no siempre se distingue bien.

Qu茅 es un test de UI

Los tests de interfaz de usuario (UI):

  • 脷nica y exclusivamente testean la UI.
  • Testean c贸mo reacciona la UI ante diferentes configuraciones de la l贸gica subyacente.
  • Testean c贸mo reacciona la UI ante eventos e usuario at贸micos.

Para poder abstraer la UI del resto de la l贸gica son fundamentales una arquitectura y dise帽o correcto basado en cualquier patr贸n testable. Por ello, seguir los principios SOLID es muy importante. No solo para realizar un buen desarrollo, sino tambi茅n para poder tener una buena testabilidad.

Es frecuente encontrar algo de confusi贸n al respecto, ya que no todo lo que usa la UI para probar es un test de UI. Si estamos probando cualquier tipo de l贸gica no relacionada con UI usando eventos y asertos de UI, quiz谩 no estamos haciendo algo bien. Puede que el test no este bien enfocado o puede que nuestro c贸digo no sea todo lo testable que deber铆a. En este punto tendremos que replantearnos qu茅 y c贸mo podemos hacer los tests para que sean lo m谩s 贸ptimos hacia nuestras necesidades.  

Qu茅 no es un test de UI

Los test de aceptaci贸n (a veces tambi茅n llamados de plataforma, end-to-end, o incluso finales)  est谩n tambi茅n muy extendidos para probar escenarios completos. Como tal, usan habitualmente la UI como punto de entrada. Eso implica, que incluso podemos usar los mismos frameworks para desarrollar tests en algunos casos, pero sin olvidar que eso no les convierte en tests de UI. 

Vamos a ver un ejemplo muy sencillo que nos ilustre esta diferencia. Usaremos una de las m谩s conocidas funcionalidades que existen: el login. Para ello, recogemos los datos del formulario por pantalla y existir谩 una l贸gica por debajo de la UI que los valida, y a continuaci贸n, devuelve el resultado. Qu茅 har铆a un test de UI ante un escenario de login correcto?

Usaremos en este ejemplo las sintaxis de Espresso y Mockito:

fun testLoginCorrect(){

    `when`(authenticator.checkCredentials(anyString(), anyString())).thenReturn(EXITO)

    //User events to fill UI components
    onView(withId(R.id.loginTextView)).perform(replaceText("username"))
    onView(withId(R.id.passwordTextView)).perform(replaceText("password"))

    //Submit the credentials to the authenticator entity
    onView(withId(R.id.buttonSubmit)).perform(click())

    //Assert the final status
    onView(withId(R.id.statusTextView)).check(matches(withText("Correct Credentials")))

}

y que har铆a un test de aceptaci贸n:

fun testLoginCorrect(){

    //User events to fill UI components
    onView(withId(R.id.loginTextView)).perform(replaceText("username"))
    onView(withId(R.id.passwordTextView)).perform(replaceText("password"))

    //Submit the credentials to the authenticator entity
    onView(withId(R.id.buttonSubmit)).perform(click())

    //Assert the final status
    onView(withId(R.id.statusTextView)).check(matches(withText("Correct Credentials")))

}

casi iguales, 驴verdad?. Pero la realidad es que son tests muy diferentes. En el caso del test de UI, estamos incluyendo una respuesta fake (gracias a Mockito), que nos asegura que la l贸gica que comprobar谩 las credenciales no esta involucrada en este test. Dicha l贸gica tendr谩 sus propios tests, que ser谩n t铆picamente unitarios y separados por completo de estos y de cualquier otro componente o capa de dise帽o con la que pudiera estar relacionado. En el caso del test de aceptaci贸n, la misma l贸gica que validar谩 las credenciales en producci贸n estar谩 presente en el test. 

La diferencia, como ya hemos comentado, es el scope de la prueba. La abstracci贸n permite en el primer caso asegurar que los asertos se centran en la UI. Mientras, en el segundo, un fallo en la l贸gica subyacente har铆a fallar el test independientemente del comportamiento esperado de la UI. Pero leemos el c贸digo y son pr谩cticamente iguales, de ah铆 que no siempre la distinci贸n sea clara y cristalina.

Por donde empezar

Por citar algunos frameworks 煤tiles a la hora de desarrollar tests de UI para apps m贸viles: KIF, Earlgrey (iOS), Espresso, Robotium (Android). Si nos interesa un 谩mbito de aceptaci贸n, podemos citar Calabash en el mundo m贸vil. Conoces alguno de ellos? cual es tu preferido? 

En Solid GEAR trabajamos en diferentes proyectos desarrollando tests de distintos tipos sobre los productos. En el caso de ownCloud, mi compa帽ero David Gonz谩lez y yo desarrollamos tests para cubrir las necesidades de la aplicaci贸n de Android, tanto unitarios como de UI.

Art铆culos relacionados:

Deja un comentario

Responsable 禄 Solidgear.
Finalidad 禄 Gestionar los comentarios.
Legitimaci贸n 禄 Tu consentimiento.
Destinatarios 禄 Los datos que me facilitas estar谩n ubicados en los servidores SolidgearGroup dentro de la UE.
Derechos 禄 Podr谩s ejercer tus derechos, entre otros, a acceder, rectificar, limitar y suprimir tus datos.

驴Necesitas una estimaci贸n?

Calcula ahora