marzo 16th, 2011 by David Vílchez Mendoza | Posted in articulos, eventos, tdd | No Comments »
Este fin de semana tuvo lugar el segundo sábado áxil de la comunidad áxil-mente de Galicia. En dicho evento pude proponer una charla sobre BDD, después de escuchar las opiniones de todos y ordenar un poco mis ideas voy a intentar expresar mi opinión al respecto.
Yo soy de los que piensan que BDD es TDD bien hecho. Tengo que reconocer que esta opinión provoco ciertas sonrisillas y tal vez merezca la pena una aclaración.
Al principio, al menos en “mi” principio, TDD era una de las practicas de XP y consistía en escribir un test antes de empezar a escribir código. Solo eso. ¿Y BDD? BDD es todo lo que TDD quiso ser y no le dejaron. Escribir los test antes que el código tiene una serie de beneficios intrínsecos. Tenemos mucho más que una extensa red de seguridad para hacer refactoring o cambiar algo en nuestro código. Lo cierto es que también nos ayuda a obtener un mejor diseño, a desacoplar más nuestras clases, a centrarnos más en lo que estamos haciendo, a diseñar nuestras APIs desde el punto de vista de quién las consume y un largo etc. Por tanto TDD merecía un nombre más ambicioso, entonces llego BDD.
La primera persona que hablo sobre BDD fue Dan North. En su artículo habla sobre todo el proceso que siguieron él y algunos amigos hasta dar con lo que llamaron BDD. Os animo a leer el artículo con atención. Para mí la palabra clave es “behaviour”. Si quitamos la palabra test de nuestro proceso de desarrollo favorito y ponemos comportamiento no tendremos una batería de test que ejercita nuestras clases y métodos, tendremos el comportamiento de nuestros objetos expresado en forma de test. Esa es la clave.
Un poco de código:
Ejemplo en TDD:
1: [TestClass]
2: public class CalculatorTests
3: {
4: [TestMethod]
5: public void AddTest()
6: {
7: var calc=new Calculator();
8: var result = calc.Add(3, 2);
9: Assert.AreEqual(5,result);
10: }
11: }
Ejemplo en BDD:
1: [TestClass]
2: public class CalculatorSpecs
3: {
4: [TestMethod]
5: public void given_two_natural_number_when_add_then_result_is_ok()
6: {
7: var calc = new Calculator();
8: var result = calc.Add(3, 2);
9: Assert.AreEqual(5, result);
10: }
11: }
¿Pero qué aporta BDD? Bueno, primero desterrar de una vez por todas la T(est) de su nombre, algo que muchos pedían a voz en grito. Y segundo, otra serie de beneficios, por ejemplo: la mejor documentación de tu código estará en tus test, serán menos frágiles o al menos mentirán menos ya que prueban el “qué “ y no el “cómo”, incluso, si tienes suerte, puede que tus clientes escriban los criterios de aceptación de sus historias usando Gherkin y cerrarás el círculo como hace Dan North en su artículo.
Algunos dicen que BDD son test de aceptación. Yo pienso que un test tanto si es de aceptación, de integración, unitario o lo que sea debe y puede expresar un comportamiento. Otros hablan de niveles y dicen que BDD solo se puede aplicar a niveles más externos de la aplicación dejando TDD para las capas más internas y cercanas al desarrollador. Mi opinión es que estas confusiones las han provocado los framework y sus notaciones a la hora de expresar los comportamientos. Así tenemos Given/When/Then o Context/Specification. Pero no podemos dejar que estos frameworks nos digan dónde podemos usar BDD. Si para ti no es natural expresar los test de tus capas más internas con GWT entonces no lo uses, usa cualquier otra forma que te sea útil (can_add_two_numbers por ejemplo).
BDD es la forma de hacer TDD del siglo 21, ¿te lo vas a perder?
Para saber más:
