Es habitual en muchos proyectos que nuestro cliente nos defina unas funcionalidades que quiere que nuestro producto le proporcione. Documentamos esas funcionalidades, las diseñamos y las desarrollamos pero cuando el cliente las ve, o peor aún, cuando se ponen al uso de todos los usuarios vemos que no satisfacen sus necesidades reales o contienen defectos. Es ahora cuando empezamos a retrasarnos en nuestras entregas, el presupuesto se nos va de las manos y encima de todo esto, el cliente no tiene lo que esperaba.
Para intentar evitar estos problemas, en lugar de hacer un gran esfuerzo de diseño antes de comenzar a desarrollar (Big Design Up Front) podemos utilizar la técnica Agile, Behavior Driven Development (BDD) que pregunta a los usuarios e interesados por el comportamiento que debe tener la aplicación antes y durante el desarrollo evitando fallos en la comunicación. La meta de BDD es la validación de los requisitos (construir la funcionalidad correcta) y no la verificación (construir correctamente la funcionalidad)
Tal como pude verse en el curso CS-169.1x Software as a Service (de edx.org, lo recomiendo siempre que lo menciono) podemos usar herramientas como Cucumber para dirigir el desarrollo por el comportamiento que debe tener la aplicación.
Por ejemplo, si quisiéramos comprobar una funcionalidad (
feature) de nuestro producto por la cuál una película añadida a la base de datos debería aparecer siempre en el orden correcto, escribiríamos:
Feature: movies when added should appear in movie list
Scenario: view movie list after adding movie
Given I have added «Zorro»
And I have added «Apocalypse Now»
And I am on the RottenPotatoes home page sorted by title
Then I should see «Apocalypse Now» before «Zorro»
Como podemos ver esto es lenguaje casi natural y por tanto fácilmente entendible por el cliente de forma que podrá validarlos e incluso él mismo podría escribir estos tests.
Para que un step como Given I have added «…» funcione tendríamos que escribir algo como esto:
Given /I have added «(.*)»/ do |title|
steps %Q{
Given I am on the Create New Movie page
When I fill in «Title» with «#{title}»
And I press «Save Changes»
}
end
Given, And y Then son alias para el mismo comando y solo existen para hacer el texto más entendible por los humanos. A su vez tendríamos que crear las funciones para Given I am on …, When I fill … pero como nos podemos imaginar después de escribir unas cuantas funciones como éstas tendremos un repertorio de pasos (steps) con los que podremos escribir la mayoría de tests.
Ya saben, mejor testear que debuguear.
