BDD en Android con Calabash
26-09-2012
jbeerdev
Clasificado como:
Android ,
BDD - Behaviour Driven Development ,
DESARROLLO DE SOFTWARE ,
Hace ya algún tiempo que vengo trabajando con Robotium, un entorno para crear test a nivel de UI en Android. Robotium ofrece una gran potencia al desarrollador para crear test a alto nivel, pero. ¿Qué pasa si alguien con poco conocimiento de programación quisiera trabajar en este entorno para crear test?
Esta es una de las cosas “malas” que tiene Robotium, que has de saber un poco de programación, un poco de Java y de Android para poder hacer los tests rápida y eficientemente. Robotium es un framework para desarrolladores. Con Robotium, implicar a los encargados de producto (Product Owners, PO, a partir de ahora) en la elaboración de test que se encarguen de validar las historias de usuario se hace bastante complicado.
A todo esto, aparece en escena Calabash, framework basado en Cucumber (y haciendo uso de Robotium a más bajo nivel) para hacer “test de aceptación” en Android. Creo que esto es lo que andaba buscando, un framework en Android para hacer BDD (Behavior Driven Development).
Un test con Calabash quedaría tal que así:
Feature: Edit profile feature
Scenario: I can edit user Z name
Given I log as user "Z"
And I enter in the edit profile screen.
When I enter "Jbeerdev" as username
And I save the changes
I can see "Jbeerdev" in user name field
…….
Scenario: I want to enter in the About screen
When I press "About"
Then I wait up to 5 seconds for the "About" screen to appear
Then I see the text "About this aplication"
Frente a un test de Robotium.
public void testPreferenceIsSaved() throws Exception {
solo.sendKey(Solo.MENU);
solo.clickOnText("More");
solo.clickOnText("Preferences");
solo.clickOnText("Edit File Extensions");
Assert.assertTrue(solo.searchText("rtf"));
solo.clickOnText("txt");
solo.clearEditText(2);
solo.enterText(2, "robotium");
solo.clickOnButton("Save");
solo.goBack();
solo.clickOnText("Edit File Extensions");
Assert.assertTrue(solo.searchText("application/robotium"));
}
Queda mucho más claro y conciso para personas que están fuera del mundo del desarrollo. Aún así, hay que aprenderse un nuevo “lenguaje”, ya que Calabash tiene sus pasos predefinidos. Nosotros haciendo uso de código Ruby, podemos crear mediante macros y funciones nuevos pasos más complejos. La siguiente función define el paso “When I enter ‘Jbeerdev’ as username”
require 'calabash-android/calabash_steps'
When /^ I enter "([^\"]*)" as username$/ do |user|
macro %Q[I enter "#{user}" into input field number 1]
end
En esta macro, paso por parámetro el usuario que quiera poner en el campo “username” (que en este caso es el primer campo de entrada que encontremos en la pantalla, field number 1).
Cada macro puede complicarse tanto como se quiera, añadir tantos pasos como se quiera, incluso hacer uso de estructuras de datos “más complejas” (como por ejemplo guardar en una colección los datos del usuario “Z” para hacer referencia a ellos usando claves como “username”, “password”, “userQuote”..).
Usar Calabash “a pelo”, sin montar ninguna macro por detrás y usando solamente las expresiones y pasos que nos proporciona el framework puede ser también algo duro para los PO, aunque el lenguaje es “casi natural” , todavía tienen que aprenderse unas expresiones fijas y conocer ciertos aspectos de la aplicación. Es sin duda mucho mejor montarse una buena serie de macros y expresiones que “oculten” al PO algunos datos de la aplicación que no tienen porqué saber, como puede ser que el campo “usuario” cuando se hace un login, es el número 2 de la pantalla.
Mucho mejor
When I enter "jbeerdev" in the username field
que
When I enter "jbeerdev" into input field number 2.
¡Pero entonces, todavía se sigue dependiendo de los desarrolladores para hacer estos test! “Yo soy developer, no tester”, he escuchado decir a algunos compañeros. “Entonces sigamos usando Robotium, total, vamos a tener que aprender Ruby nosotros también”, he escuchado decir a otros compañeros. Veamos… desde mi punto de vista el testing no es una función exclusiva de los llamados “Testers” por contrato en una empresa. El desarrollador ha de hacer también testing, y bueno, en empresas en las que las funciones están altamente definidas, que un desarrollador y un tester trabajen mano a mano con un PO para crear estos tests, algunos pueden considerarlo una “pérdida de tiempo” o “un desaprovecho de las capacidades de los developers”, yo no lo veo de esa manera.
En definitiva:
Ventajas de Calabash frente a Robotium
- Puedes implicar a gente no-técnica en proceso de creación de Tests.
- Uso de lenguaje “natural”.
- Fáciles de gestionar y mantener.
Desventajas de Calabash frente a Robotium
- Con Robotium teníamos acceso a las “tripas” de la Aplicación y se podían hacer “cosas sucias” como borrar los registros de una base de datos con una línea.
- No poder arrancar la batería de test en un punto concreto de la aplicación. Con Calabash siempre hemos de empezar la aplicación desde el punto inicial, Robotium nos permitía arrancar cualquier Activity que deseáramos.
- Hay que aprenderse otro lenguaje “extra” en el caso de querer profundizar un poco más en el framework. (Pero… ¿Es esto una desventaja? 
)
Si os interesa el tema os recomiendo que sigáis el blog de los chicos de LessPainful.
Gracias por el post y por el hangout, estuvo muy bien. Y gracias por nombrar nuestro libro en el hangout.
El ejemplo con Cucumber de este post va un poco en contra de lo que los propios autores de Cucumber recomiendan porque expone detalles de como esta implementada la solucion en lugar de explicar el “que”. Usas un modo imperativo en lugar de descriptivo.
En esta charla a la que tuve la suerte de asistir en directo, lo cuentan Matt muy bien:
http://skillsmatter.com/podcast/java-jee/why-your-step-definitions-should-be-one-liners-and-other-pro-tips
Sigue publicando