TDD/BDD – Segundo sábado áxil
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:
- http://en.wikipedia.org/wiki/Behaviour
- http://dannorth.net/whats-in-a-story/
- http://blog.michaelbrennan.net/2009/09/introducing-context-specification.html
- http://saraford.net/2004/10/28/developing-a-test-specification/
- http://inter-sections.net/2007/10/03/the-difference-between-tdd-and-bdd
@axilmente en la #kutruparty
Al final @pvcarrera, @pepellou y un servidor conseguimos reunirnos para un minievento técnico en la kutruparty. Se nos unieron seis interesados, y como no sabíamos muy bien que nos íbamos a encontrar todo fue bastante improvisado. Empezamos explicando brevemente conceptos básicos sobre pruebas automatizadas e implementamos una calculadora que “sabia” dividir. Después introdujimos TDD y para asentar los conocimientos dedicamos un pomodoro de 45′ a implementar FizzBuzz. Para terminar @pepellou propuso una mesa redonda en la que hablamos sobre incorporar lo que habíamos visto hasta ese momento en nuestro día a día.
La verdad es que creo que a pesar de lo precipitado que acabo siendo todo, fue un éxito.
Quiero darle las gracias a Adrián y al resto de la organización de la kutruparty por alojarnos y colaborar con todos los medios a su disposición.
1º Sábado Áxil de la comunidad axilmente
El pasado Sábado día 20 de Noviembre fue el primer sábado axil de la comunidad ágil gallega. Tal acontecimiento tuvo lugar en el Centro Sociocultural e Xuvenil Municipal “O Ensanche” en Santiago de Compostela.
La jornada empezó escribiendo en una pizarra los temas que nos interesaban, después votamos y al final llegamos a un acuerdo salomónico de cómo organizar el día. Todo muy bien guiado por @jpenalta.
Al final durante las dos horas de la mañana hicimos dos tracks en paralelo uno de iniciación y otro más avanzado. No hubiese estado mal que hubiera ido al de iniciación pero me pareció que habría más discusión el avanzado y allí me fui.
En primer lugar hablamos sobre scrum en entorno multiproyecto una mesa redonda propuesta por @carlisgg. La charla estuvo bastante interesante, @mpermar, @pepellou, @pvcarrera y otros que aún no tengo “virtualizados” compartieron sus experiencias y surgieron algunas ideas que espero que @carlisgg pusiera en práctica y en la próxima nos comente que tal le fue.
La segunda trato sobre contratos ágiles, propuesta por @pvcarrera, muy interesante también. Además había gente que tenía experiencia en tratar con las administraciones publicas y hablamos sobre cómo podría encajar un contrato ágil en la administración.
Después nos fuimos a comer con el resto de la tropa. @davidesmerodes hizo buenas migas con un tal Milo y nos consiguió una comida de primera. Las cuatro horas que tuvimos para degustar los fabulosos platos de la cocinera ganadora del permio milenium se pasaron volando. Durante la comida hablamos de muchísimas cosas pero los efectos del vino no me permiten contáoslas.
A la vuelta de la comida llego el momento técnico. @pvcarrera y @pepellou hicierón una demostración magistral de tdd codificando la conocida kata FizzBuzz. Pasado el pomodoro desenfudamos los portátiles y en parejas nos pusimos con Roman Numerals durante dos pomodoros. Después una retrospectiva rápida y a la retrospectiva de verdad.
@davidesmerodes tiro de lápiz y pizarra y nos guio en la retrospectiva. Salieron muchas cosas interesantes pero… no le hice una foto a la pizarra. De todos modos yo me quedo con lo de saber que no estamos solos, que somos más de un pirado en esto de hacer las cosas mejor cada día y que en Enero será la segunda de una larga lista de sábados agiles.
Adjunto por si a alguien le interesa mi implementación de la kata Roman Numerals: código en codeplex
Por favor ayúdame a mejorar, critícame.
Otros que también lo contaron:
Mi experiencia con Android (1)
Después de mucho tiempo utilizando Windows Mobile (desde 2003 aproximadamente) calló en mis manos una Htc Magic. Fue entonces cuando me di cuenta de lo frustrante que es la experiencia Windows Mobile para el usuario.
Android lo hace todo tan sencillo y funciona tan bien que el paso de un sistema a otro fue muy natural, nada traumático.
Ya metido en harina me hice con una Htc Desire, la misma que actualmente me acompaña a todos sitios. Mucho podría escribir aquí sobre las diferencias entre ambos sistemas y sobre mi experiencia con Android pero para eso ya hay grandes fuentes de donde beber:
El caso es que después de un tiempo con la rom original decidí rootearla y ponerle una rom cocinada. La elegida después de algunas pruebas fue OpenDesire. Una rom muy equilibrada con muchas características que no trae “out of the box”, muy rápida y sin los programas que le mete htc a su desire, eso quiere decir también sin htc sense. He tenido esta rom durante un par de meses pero a cada nueva versión se resolvia algun problema y aparecía otro. Pequeños problemas no obstante pero siempre un pero. Total que recientemente decidi volver a la rom original.
El problema de la rom original es que trae algunos programas que no se pueden desinstalar y que si no estas rápido y se lo impides se conectan a Internet y consumen batería. Después de buscar un rato encontré la forma de eliminar dichas aplicaciones:
Borrar aplicaciones Htc SENSE
adb shell
mount system
cd system
cd app
ls
rm *Friend*
rm *PDFView*
rm *Twitter*
rm *Stack*
rm *Quicko*
rm *Foot*
El resultado fue genial, el consumo de batería era menor y sin programas que no quería. El problema llego con una actualización de la rom original.
Pues sí, resulta que si eliminas dichos programas y despues intentas instalar una actualización oficial fallará. El primer fallo es sobre la firma. Tienes que decirle al recovery que se salte esa comprobación. El siguiente error es que no encuentra alguna de las aplicaciones borradas. Mi solución fue restaurar la rom y aplicar el update. También podrías guardar una copia de dichos programas y restaurarla antes de una actualización.
De momento yo sigo con esos programas instalados, eso sí, bien configurados para que no se conecten a Internet.
Aturdido y abrumado
Aturdido y abrumado así me encontraba cuando @ecomba me pregunto: “¿Que sientes?”.
Estábamos en la tercera retrospectiva del día. ¡Vaya pregunta! os diréis, pero realmente tenia sentido.
Las dos primeras iteraciones habían transcurrido con normalidad. Creía que sabia lo que estaba haciendo, al menos en la segunda. La primera fue… ¿como decirlo? como si te sacaran a oscura de casa y te pusieran a programar en un ordenador que no es el tuyo y te pidieran que rehicieras el kernel de linux. Bueno… tal vez no tanto, pero soy andaluz. El caso es que me encontraba extraño y nervioso. Era la primera vez que practicaba pair programming, además de cuando en cuando tenia un tío detrás de mi cogote que no decía nada pero cuya cara era un poema. La segunda, sin embargo, fue sobre ruedas. Pero llego la retrospectiva y fue toda una bofetada, ¿Qué es eso de mundo? ¿ Dónde pone vecindario? ¿Qué es una celda?…. ¿Qué estaba pasando?
Entonces @ecomba nos orientó: “Quiero que hagáis TDD de la siguiente manera: Escribid primero el assert. Después el código necesario pero todo dentro de la mima clase de test. Solo cuando os pida a gritos que la saquéis a una clase lo haréis… Ah por cierto… no uséis if ni métodos de más de 4 lineas”.
Bueno, fue un poco frustrante pero seguí adelante. La putada fue que justo antes de que pasaran los malditos 45 minutos del maldito pomodoro @ecomba vino a nuestro lado y nos dijo: “¿Que es muerto?”. Acto seguido borramos todo el código. Lo que nos devuelve al principio de la historia.
Despues de preguntar por nuestro estado de ánimo nos alentó a continuar empezando por definir las reglas de muerte y vida.
Creo que al final del quinto pomodoro todos habíamos comprendido perfectamente las reglas del juego de la vida, algo que no nos habíamos molestado en hacer la primera vez que nos pusimos a programar. Además les habíamos puesto nombre, y no cualquier nombre, nombres coherentes y oportunos. Habíamos luchado con el “naming”.
En la última iteración nos pidió que consideráramos la variable temporal del problema. Esto nos ayudo a juntar todas las piezas del puzzle que antes nos había hecho construir.
¿Qué aprendí? Es difícil decirlo. Y eso que parte del tiempo que pase pensando lo hice intentando descubrir el propósito del juego de @ecomba.
Como conclusión puedo decir que con frecuencia no analizamos en profundidad el problema, nos basamos en nuestra experiencia o en ideas preconcebidas que conducen nuestro TDD. Hay que fijarse más en el dominio y tal vez TDD no solo sirva para que el diseño emerja sino también para clarificar el dominio que queremos modelar. También que los nombres son muy importantes, las palabras son muy importantes, que el pair programming es genial y muy enriquecedor, que cada lenguaje es una pequeña joya y que si estos tíos organizan otra fiesta yo no me la pierdo (aunque me tenga que colar).
Gracias especialmente a @ecomba por regalarnos su tiempo a @autentia por el patrocinio y a todos los que estuvieron allí, que son muchos, por compartir un poco de código conmigo.
Otros que también lo contaron:
¿Quién no quiere un Nexus One?
Pues yo desde luego quiero uno y si encima me lo regalan los chicos de El Androide Libre mejor que mejor. Si vosotros malditos insistís en minimizar la probabilidad de que me toque aquí tenéis las bases.
Suerte,
En defensa de los derechos fundamentales en internet
Manifiesto “En defensa de los derechos fundamentales en internet”
Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…
1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial – un organismo dependiente del ministerio de Cultura -, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.
Este manifiesto, elaborado de forma conjunta por varios autores, es de todos y de ninguno. Si quieres sumarte a él, difúndelo por Internet.
The Three Laws of TDD.
Conviene repetirlas mentalmente 10 veces 
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
via:butunclebob.com
CodCamp .NET 2009
Otro año mas que no puedo ir a la CodeCamp, esta vez tengo una buena razón… me caso J.
Si vosotros podéis ir:
http://www.codecamp.es/CodeCamp/tabid/39/language/en-US/Default.aspx
