¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
techbiz
Raúl Martínez 26/04/2017 Cargando comentarios…
En los últimos tiempos, la metodología Test Driven Development se ha ido imponiendo como una forma de trabajo y un cambio de mentalidad en el mundo IT, pero lamentablemente siempre existen excepciones dentro de este sector, ya sea por mentalidad (“esto no vale para nada”) o bien por los deadlines que nos apremian (“esto es una pérdida de tiempo”).
Vamos a tratar de exponer a modo de introducción en qué consiste, cuáles son sus principios básicos, qué supone implantar esta metodología y qué ventajas nos aporta. ¿Preparados?
TDD son las siglas de Test Driven Development. Es un proceso de desarrollo que consiste en codificar pruebas, desarrollar y refactorizar de forma continua el código construido.
La idea principal de esta metodología es realizar de forma inicial las pruebas unitarias para el código que tenemos que implementar. Es decir, primero codificamos la prueba y, posteriormente, se desarrolla la lógica de negocio.
Es una visión algo simplificada de lo que supone, ya que bajo mi punto de vista también nos aporta una visión más amplia de lo que vamos a desarrollar. Y en cierta manera nos ayuda a diseñar mejor nuestro sistema (al menos, siempre ha sido así desde mi experiencia).
Para que un test unitario sea útil y esta metodología tenga éxito, previamente a comenzar a codificar, necesitamos cumplir los siguientes puntos:
"Una clase solo debe tener una razón para cambiar".
La clase programador debe funcionar correctamente con la clase Vehículo o con cualquier subclase de ella. El LSP es susceptible de ser violado cuando ocurren situaciones del tipo de la imagen de la derecha.
El ciclo de vida de TDD se basa en una continua codificación y refactorización. ¿Cómo hacemos esto?
En los diversos proyectos en los que he trabajado a lo largo de mi carrera profesional, me he encontrado con la imposibilidad de implantar o animar a los responsables a cargo de cambiar la filosofía de trabajo (no siempre, afortunadamente).
Como he contado al principio del post, siempre nos encontramos con los típicos casos en los que no ven utilidad en implementar dicha metodología. Las “excusas” siempre son del mismo tipo, desde “esto no vale para nada”, “no tenemos tiempo”, “no estoy acostumbrado”...
En general, y bajo mi punto de vista, estas frases se sueltan desde el desconocimiento y la falta de visión a la hora de ver sus ventajas. Yo mismo pensaba eso al principio (cuando eres joven se dicen muchas tonterías), pero cuando ves que no es así...
En general, en los proyectos donde he usado TDD, me ha ayudado a detectar requisitos que faltaban por parte de negocio, diseñar mejor mi lógica de negocio separando componentes y capas (ayuda en ciertos casos cuando algún miembro del equipo es muy dado a acoplar en demasía el código), y prevenir errores.
Desconozco si habrá sido buena suerte (aunque en nuestro sector sabemos que normalmente la suerte no está de nuestra parte cuando se trata de un desarrollo complejo), pero en estos proyectos el número de errores se ha reducido drásticamente respecto a otros donde no he utilizado TDD (también hay otros factores, como la parte técnica, la organización y la comunicación que obviamente, influyen).
Para el programador es un cambio grande en su mentalidad, en su forma de procesar y gestionar la información. Cuesta acostumbrarse al principio, pero llega un momento en que su productividad y eficiencia a la hora de codificar los test y de desarrollar de forma simplificada el código se incrementa y resulta muy productivo.
Si un test está bien escrito y bien definido, podemos casi asegurar que nuestra lógica de negocio es correcta, y que lo que puede fallar en una posible incidencia puede venir principalmente de los datos que nos proveen sistemas externos. Esa es una forma también de acotar errores.
Por ejemplo, no hace mucho que me encontré un caso en el cual los gastos de envío de una compra eran de 0,0€. Como sabía que era bastante improbable que mi desarrollo fuera el causante (ya que estaba bien cubierto por pruebas unitarias), me di cuenta que el error provenía de una caché externa que rellenaba una serie de tablas, cuya finalidad era la de devolver una serie de campos necesarios para calcular el importe.
Al final, ahorras en tiempo de debugging y focalizas los posibles problemas de forma rápida y eficiente. Eso se traduce en menos horas de mantenimiento y “bucear” por el código para ver qué puede estar fallando. Algo en lo que a lo mejor hubiese tardado 1 hora, tardé tan solo 10 minutos en deducir.
La principal desventaja que veo a esta metodología es que no es válida (al menos bajo mi punto de vista) para test integrados, ya que necesitamos conocer los datos del repositorio y verificar que el contenido es el esperado después de realizar una transacción (o un rollback en su defecto), lo cual, al final,requiere tener especial cuidado y un sistema de gestión para un BBDD (aunque sea en memoria, que sería lo ideal).
Para este tipo de test integrados o funcionales hay frameworks como Concordion que ofrecen soluciones interesantes, aunque eso es un tema que podemos tratar en otro post.
Por tanto, ¿qué ventajas nos ofrece TDD?:
Os animo a que experimentéis esta forma de desarrollar vuestras aplicaciones en la medida de lo posible, (bajo mi punto de vista merece la pena), o al menos que lo conozcáis, porque cada día está más extendido en nuestro sector.
Y desde luego, no tengo la verdad absoluta, ya que dentro de cada equipo de trabajo se discute “a lot of times” sobre cómo llevarlo a cabo de la mejor forma posible y seguramente haya pasado por alto muchas cosas, aunque un post al final se reduce a intentar explicar y desarrollar de forma simplificada una idea basada en la experiencia de uno.
Por último, os recomiendo el libro de Kent Beck, “Test Driven Development: By Example”, material muy interesante por parte de uno de los gurús sobre este tema.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Estamos comprometidos.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.