Las siguientes notas estan basadas en ideas de Hernan Wilkinson (10Pines), compartidas en el Agiles 2015 y en un Curso de TDD realizado en Everis Chile.

Charla: «Como hacer TDD y no morir en el intento»

Esta presentación, disponible libremente en la web, corresponde a su charla comunitaria del Agiles 2015 en Uruguay:

Curso: «Construcción de software seguro/robusto usando TDD»

Las siguientes son las notas o apuntes de este curso realizado en Everis Chile:

• TDD no garantiza un buen diseño. TDD puede ser contraproducente si no hacemos un buen diseño.
• No se puede hacer TDD en un sistema existente. Debemos primero hacer testing hasta que el sistema este robusto para hacer TDD.
• El framework puede ayudarte o hacerte más dificil hacer TDD. No casarse con un framework. El framework practicamente debe estar pensado para usar TDD.
• Extrapolar una kata sencilla a un sistema no es fácil.
• Hacer TDD en interfaces de usuario no ayuda, porque las interfaces son muy cambiantes.
• Cuando pienso el software desde el punto de vista de Turing, es un conjunto de instrucciones que dado un input genera un output. Cuando pienso el software desde el punto de vista de Lambda calculus, es un modelo computable de un dominio de problema de la realidad. Lo que pasa a ser importante es el mapeo que yo estoy haciendo de la realidad. Pensamos en hacer un buen modelo y no en rendimiento y aspectos técnicos.
• Si nosotros en nuestra profesión no conocemos nuestra historia nos pasamos reinventando nuevamente la rued: la rueda pinchada (Es como un fisico que no conozca a Einstein o a Newton).
• LISP: Representar un buen modelo.
• Pensar de una manera distinta para abrir la mente y luego decidir que es mejor.
• Las metodologias agiles son una revolucion sobre la forma arcaica de desarrollar software.
• La gente que hace las cosas sería la más adecuada para saber como hacerlas. Las Universidades crean modelos teoricos de influencia que no necesariamente son buenos. La agilidad surge de quienes hacen software, de la industria.
• «Dejen de decirnos como desarrollar software».
• Si una empresa vende productos, debe modelar la venta y el producto. No solemos modelar lo que no vemos, sin embargo, hay cosas que solo estan en nuestra cabeza y debemos modelarlas.
• Nos enseñan como computar un problema y no como modelar un negocio.
• El negocio no debería verse impactado por la infraestructura que lo ejecuta.
• Nuestro diseño y nuestro modelo están en el código fuente.
• Los desarrolladores son los arquitectos, el código nuestro diseño, los obreros los lenguajes y frameworks, y la construcción final nuestro software funcional. Si hacemos una analogía, esta sería la correcta. El obrero debe seguir lo que dice el diseño: el lenguaje debe seguir lo que dice el código. -Ver video Lone Star Ruby Conference 2010-.
• Es muy comun confundir las herramientas que uno usa con la esencia de lo que se hace. El test es la herramienta que usamos para desarrollar software robusto.
• xUnit es para más que pruebas unitarias. Los test unitarios no son los más valiosos, son los funcionales.
• El sistema legacy es aquel que yo supe que tenía que modificarlo y no me animé a hacerlo.
• No es que se dieran cuenta de que lo que hacíamos era una ingeniería, sino que querían que fuera una ingeniería. -NATTO 1968-
• El desarrollo de software es adquisición de conocimiento y representación del conocimiento: un proceso de aprendizaje. Todo sistema de aprendizaje es inherentemente iterativo, incremental, constructivista. El proceso es iterativo e incremental y el desarrollo en sí mismo es iterativo e incremental.
• Porque tenemos que usar capacidad mental para simular una computadora si tenemos una computadora. Necesitamos feedback inmediato. Nos podemos enfocar en lo mas importante.
• Lo más importante de TDD: Técnica de aprendizaje iterativa, incremental, constructivista, basada en el feedback inmediato que recuerda todo lo aprendido y permite asegurarnos de no haber desaprendido. Incluye análisis, diseño, programación y testing.
• Cuando hago TDD el test me va guiando, no lo que yo imagino que es la mejor solución; en este último caso sería testing.
• Si el test no falla al inicio, o no aporta valor, estoy testeando algo que ya existe, o yo me adelanté a la solución, hice más de lo que tenía que desarrollar, no lo mínimo necesario.
• Escribir un test al inicio es lo más dificil de TDD porque implica un cambio cultural.
• El refactoring tiene que ver con la parte artística de nuestra profesión, tiene que ver con diseño, lo determinante para evitar el código legacy: un código del que estemos orgullosos.
• TDD no es testing, apoya el testing solamente.
• El segundo paso de TDD busca feedback inmediato.
• No usar un mal nombre para un test, si es necesario, dale un nombre sin significado. Un mal nombre se intenta validar con el tiempo, un nombre sin significado pide que le cambien el nombre.
• NULL the billion dollar mistake. Tony Hoare.
• El nombre de un test debe sintetizar las tres partes del test.
• El nombre de un test nunca se debe escribir a partir de un dato de prueba, sino de un caso de prueba.
• Siempre hay que empezar por el modelo de negocio, desacoplado de la parte técnica.
• Solo hay que simular lo que esta fuera.