Continuamos con las acciones de mejora / compartiendo videos cleancoders. En esta ocasión toca el resumen del Capitulo 6 Parte 2
Este capitulo está lleno de detalles interesantes, por lo que voy a hacer varios posts para resumirlos...
Comencemos....
@unclebob, comienza con una sesión (ligera) de diseño de la solución al problema, el la que:
- Obtenemos el vocabulario del sistema
- Identificamos los componentes básicos
@unclebob Comienza con una estructura de test y un test vacío de forma que se verifica que todo está en su sitio antes de comenzar la sesión de TDD propiamente dicha.
Al principio, cuando todavía no hemos entrado en el problema, podemos identificar los primeros pasos haciéndonos la siguiente pregunta: ¿Qué test tengo que escribir para forzarme a escribir el código que se que quiero escribir?
Es común escribir un test, simplemente para poder escribir cierto código inicial de producción y que luego, según evoluciona la solución, ya no tenga sentido (o no pruebe nada) y se elimine (canCreateGame, canRoll, …)
Nunca escribimos tests que sabemos que van a pasar.
El código de los tests es tan importante como el de producción y tenemos que tener el mismo cuidado con el. Es decir tiene que ser clean code y se debe refactorizar de forma continua.
En muchas ocasiones, desarrollando con TDD, el resultado no se corresponde con el diseño original. Normalmente es más sencillo, puesto que sólo tiene el código necesario para la funcionalidad actual.
Respuestas a las objeciones típicas a usar TDD:
- Objeción: Se debe de tardar más con TDD, puesto que se escribe mucho código de test... Se tarda mucho menos, puesto que se avanza más rápido trabajando siempre sobre clean code, además se gasta mucho menos tiempo en depuración. No nos pasamos todo el tiempo peleando con código sucio y dificil de entender.
- Objeción: Los managers no dejarán practicar TDD a los desarrolladores... Es una práctica interna, que no tiene porqué entrar en discusión con los managers.
- Objeción: Refactorizar es volver a realizar trabajo, seria mejor hacerlo bien a la primera... Asi es la vida... efectivamente es volver a realizar el trabajo, pero lo normal (y adecuado) para trabajos creativos es hacerlo de forma iterativa con pequeños cambios, puesto que es practicamente imposible hacerlo perfecto a la primera.
- Objeción: Quién/Qué prueba los test... Con TDD disponemos de dos flujos alternativos para una funcionalidad, los tests y el código de producción, por lo que cada flujo testea el otro, los tests, testean el código de producción y al reves.
- Objeción: Quizás el mantenimiento de los tests es demasiado caro... No tiene que serlo, puesto que los tests, también deben estar correctamente diseñados y deben de ser clean code, por lo que su coste de mantenimiento debe ser bajo.
- Objeción: Un test puede probar que un bug ya no se produce, pero no puede probar que no existen bugs. Es decir no puede probar que el software es completamente correcto. El objetivo no es estar 100% sino disponer de una red de seguridad que nos elimine el miedo a cambiar el codigo puesto que tenemos una confianza/certeza sobre que el código funciona correctamente muy alta.
- Objeción: TDD es un disciplina, seguir reglas en vez de pensar y usar la cabeza... Las disciplinas nos ayudan a no tener que realizar las mismas decisiones una y otra vez... Necesitamos que sea una disciplina para poder ser eficientes (tener mecanizado e interiorizada la práctica) lo que no quita para que de vez en cuando nos planteemos como mejorar la disciplina.
- Objeción: No importa si se hacen los tests antes o después del código de producción... Si se hacen los tests a posteriori, nos parecerán opcionales y se tenderá a no hacerlos o a que no sean completos, por tanto no confiaríamos en ellos. Además, haciéndolos después perdemos la ventaja de que los tests primero nos obligan a hacer nuestro diseño testable (es decir con bajo acoplamiento).
No comments:
Post a Comment