Esta semana he estado un día aplicando en mi nuevo proyecto los patrones de diseño y principios relacionados con las pruebas: DI, IoC, Mocking, pruebas unitarias, TDD.
Hoy en día están muy de moda, así que como no quiero quedarme chapado a la antigua, he decidido que como estoy empezando un proyecto nuevo en MVC, era un buen momento para ponerme con el tema. Aparte de estar muy de moda, me lo habían aconsejado (eufemismo de casi obligado).
Bueno, no voy a ser yo quien defina estos conceptos, para eso ya está la wikipedia y numerosos posts. Esto es literaturaprogramada, no un blog para repetir los que otros dicen. Tengo la intención de postear artículos técnicos, pero solo si aportan algo que no sea fácil de encontrar; no es este el caso. Espero encontrar una excusa pronto para hacerlo.
En conclusión, yo tenía una idea equivocada del concepto TDD (Definición Wikipedia) , que es el que engloba todos estos conceptos. Hacer pruebas me parece bien, pero no acababa de entender el orden propuesto pero esta práctica:
- Elegir un requisito
- Escribir una prueba
- Verificar que la prueba falla
- Escribir la implementación
Mi opinión era que, me parecía absurdo escribir la prueba(paso 2) y verificar que falla(paso 3), antes que escribir la implementación (4). El caso es que como soy muy cabezota, me he empeñado en que este orden estaba mal planteado (aunque no he llegado a presentar una queja a la wikipedia), y he hecho el paso 4 antes que el 2 y el 3.
Con esta decisión me he generado un problema. En concreto estaba probando una acción simple de un controlador. La prueba fallaba, pero la razón no era la lógica de la función que quería probar. La lógica era correcta, pero el problema es que no se podía probar porque la función tenía dependencias vinculadas al contexto de la petición Http y a la sesión. Por tanto de ahí se concluye que ese código, aunque solo cumplía un objetivo, tenía dependencias acopladas nada deseables y que era conveniente desacoplar.
Aunque la función en si misma era trivial, solo el hecho de utilizar TDD obliga a programar de forma desacoplada, siguiendo por tanto uno de los principios fundamentales de la ingenería: "Una cosa es una cosa, y otra cosa es otra cosa".
No me detendré en detallar el problema técnicamente, el objetivo del post es dar mi opinión favorable sobre el TDD. Es un placer dejaros el link de los dos posts que me han ayudado a aplicar esta técnica, a comprender mejor el TDD, y por tanto a programar mejor:
http://geeks.ms/blogs/etomas/archive/2010/06/30/asp-net-mvc-q-amp-a-c-243-mo-usar-la-sesi-243-n.aspx
En resumen, que el TDD es una muy buena práctica, en mi opinión más que por ejecutar las pruebas unitarias (que también), porque obliga a programar bien para que estas se puedan realizar.
La confusión que me generó este concepto es solo por el nombre, creo que el nombre que propongo deja más claro el concepto, y puede ayudar a otra gente a no generarse el mismo prejuicio que yo me cree. El nombre es , GDSYCT, acrónimo de "Guided Development So You Can Try" , que según el traductor de google es la traducción al inglés de "Desarrollo guiado para que se pueda probar".
Para finalizar remarco que el objetivo es programar mejor, no garantizar que el programa no vaya a tener errores, por supuesto. Seamos honestos, dentro de unos límites razonables, por nuestro bien, es deseable que un programa pueda fallar, para que el cliente/empleador necesite de nuestros servicios.
Hasta otra.
No hay comentarios:
Publicar un comentario