archivo

Archivo de la etiqueta: Test-driven development

En el artículo anterior vimos las actividades que definían al proceso de implantación y de las consecuencias de que el tiempo necesario para realizar esa actividad superasen unos umbrales admisibles para el proyecto de desarrollo de software en cuestión.

La aplicación de una metodología o enfoque ágil o la utilización, en general, de alternativas iterativas e incrementales suponen por su propia naturaleza una disminución de los tiempos de implantación, sobre todo, una vez que ya se han realizado varias evoluciones del sistema.

Sin embargo, si el tiempo necesario para realizar las implantaciones resulta superior al tiempo de iteración definido tenemos un problema ya que provoca una acumulación de las entregas y que buena parte del tiempo invertido en el proceso de implantación se pierda. Esta situación no debería mantenerse mucho tiempo y para solucionarla sería necesario retrasar una entrega hasta que se pueda subir una acumulación de evoluciones a producción.

Estas situaciones pueden producirse en más ocasiones de las que podemos pensar, ya que lo mismo los trabajos siguiendo metodologías ágiles, parten de una versión del producto avanzada y que no ha sido implantada todavía (o no se han implantado con éxito), los equipos encargados de testing y de paso a producción tienen una carga de trabajo elevada, otras prioridades, etc…

Soy de la opinión de que para poder trabajar de manera adecuada hay que estabilizar la situación, es decir, si la implantación de un producto resulta compleja o está dando problemas, hay que centrar los esfuerzos en ella y adaptar los desarrollos que se están haciendo a esa circunstancia.

Además de la aplicación de enfoques ágiles, ayuda mucho la existencia de unos entornos de integración y de preproducción los más parecidos posibles a los de reales, la aplicación de la integración continua, la utilización de técnicas de desarrollo guiadas por las pruebas (TDD) o al menos la aplicación de una estrategia adecuada de aplicación de pruebas unitarias, para reducir de esta forma la aparición de efectos colaterales y disminuir los tiempos necesarios para las pruebas de regresión y la corrección de este tipo de incidencias.

Además de lo anterior es importante que con carácter previo a la entrega el producto haya sido probado de manera adecuada por el equipo de proyecto (nada de entregas a ciegas o de pruebas superficiales).

También resulta muy adecuado el establecimiento de itinerarios de testing (todas las aplicaciones no requieren el mismo nivel de testing, ni todas las circunstancias son similares), la aplicación de testing ágil, proporcionar a los proveedores información detallada sobre las características de nuestro entorno de producción, la aplicación de una política de prioridades a los equipos encargados del paso a producción acorde a la problemática existente en cada momento, etc…

En el entorno de personas con las que trabajo existen serias dudas de que la metodología de desarrollo guiado por las pruebas o Test-Driven Development, sea ágil, en el sentido de que entienden que si se aplica de manera ortodoxa o si bien las pruebas unitarias se desarrollan después, se pierde capacidad de trabajo efectivo por parte del equipo de proyecto.

Nunca he participado en un proyecto que siga esta metodología y en los desarrollos en los que he trabajado la importancia que se le da a las pruebas unitarias es muy escasa, por lo que no puedo aportar mi experiencia para opinar sobre las bondades o no de esta metodología, de manera que me tendré que centrar en lo que he leído sobre ella.

No obstante, hay que tener en cuenta una cosa. Agilidad no es lo mismo que desarrollar más rápido o por lo menos no es su objetivo principal, ya que si bien es cierto que la aplicación de metodologías ágiles, eliminan muchos aspectos que son prescindibles en un proyecto de desarrollo de software y por lo tanto pueden optimizar tiempos de desarrollo, el objetivo último de las mismas es conseguir productos software de calidad, que proporcionen satisfacción al cliente, dentro de unos plazos y presupuestos definidos (siempre y cuando, ambos sean realistas y acordes a la naturaleza del proyecto y al nivel de calidad que se espera del producto software), es decir, que no se produzcan los factores que derivan en la crisis del software.

El desarrollo guiado por las pruebas, fue introducido (o reintroducido) por Kent Beck, creador de la metodología de programación extrema y en cierto modo la segunda es una consecuencia natural de la primera, si bien ambas pueden utilizarse sin problemas por separado.

La metodología TDD a grandes rasgos es fácil de exponer:

– Se construyen las pruebas unitarias (o se puede extender si se desea el concepto a otros tipos de pruebas de más alto nivel, siempre y cuando sea automatizable su ejecución).

Como estos casos de prueba están construidos antes desarrollarse el componente software sobre el que se va a trabajar, van a fallar a la primera. De hecho se considera necesario verificar que fallan porque si no es así, querría decir que el test está más construido (¿por qué no?) o que el componente software ya está desarrollado (en proyectos donde se trabaja con sistemas de mediana o gran envergadura y con un número de desarrolladores alto, puede pasar que el componente o módulo ya se haya implementado previamente, bien porque le ha hecho falta a un compañero para otra funcionalidad o bien porque no se ha verificado que efectivamente ese componente ya estaba desarrollado).

Para la construcción de los casos de prueba, los desarrolladores deben basarse en las especificaciones indicadas en los casos de uso o en las historias de usuario. Ahí radica la importancia que tiene la construcción de las pruebas unitarias antes del desarrollo del componente, ya que implica un mayor enfoque en los requisitos, una mayor necesidad de comprender la funcionalidad y comportamiento deseado, es decir, implica comprender el problema, conocer los resultados esperados, antes de empezar a desarrollarlo.

La ventaja de desarrollar las pruebas antes de implementar los componentes es la indicada en el párrafo anterior, es decir, enfrentarse y comprender el problema antes de empezar a resolverlo.

Si las pruebas unitarias se construyen después, no estaríamos hablando de TDD, eso es importante, por lo que lo repito, si las pruebas unitarias se construyen después se trata de otra estrategia de desarrollo de software, no de desarrollo guiado por las pruebas.

Pese a que como he comentado, no se ha fomentado en los proyectos en los que he participado la construcción de pruebas unitarias, soy de la opinión de que es favorable tener una buena cobertura de código, por lo que la existencia de pruebas unitarias, antes o después de implementar los componentes, permite detectar de manera rápida la existencia de efectos colaterales o desarrollos erróneos de métodos o clases.

¿Por qué no lo hemos fomentado? Es una suma de varios factores, por un lado pese a que entendemos los beneficios que puede proporcionar, no tenemos del todo claro su retorno de la inversión, pese a que es objetivo que la deuda técnica se reduce en proporción a la cobertura, por otro lado, los proveedores con los que hemos trabajado tampoco utilizan esta práctica en sus desarrollos. Por tanto y en resumen, la falta de experiencia nuestra y de los proveedores hace que nos más dar el paso y prioricemos otros aspectos en el proceso de desarrollo y en la calidad del diseño y de la codificación.

– A continuación se construye el componente software que debe verificar las reglas de funcionamiento definidas en las pruebas.

Una vez desarrollado, se pasa el test y si funciona adecuadamente, se pasa de nuevo todo el juego de pruebas, si hay errores, se vuelve a revisar el componente, si todo ha ido bien, se pasa a la siguiente fase.

– Una vez que se tiene un software que verifica las pruebas implementadas, se procede a su refactorización.

El objetivo de la utilización de esta técnica es evidente, desarrollar software con el menor número de fallos posible, reduciendo además los errores debidos a efectos colaterales en el desarrollo, respetando también la calidad de diseño y de codificación para favorecer la comprensión y capacidad de mantenimiento del software.

Se sabe que cuanto más tarde se detecten los errores más esfuerzo se requiere para solucionarlo, esta técnica pretende disminuir el riesgo por la presencia de errores de ese tipo, además de facilitar un código donde sea mucho más fácil trabajar, tanto para corregir esas incidencias como para contruir nuevas funcionalidades o modificar, si fuera necesario (el software es de naturaleza adaptativa), las ya implementadas.

Espero poder probar más pronto que tarde esta metodología en alguno de los proyectos en los que participo y poder verificar personalmente las ventajas que tiene la utilización de esta estrategia de desarrollo.

Una vez analizados los principios y valores del manifiesto ágil, en este artículo se va a realizar un breve perfil de sus diecisiete participantes, con el objetivo de que se pueda apreciar que todo el equipo de personas que participaron eran profesionales de reconocido prestigio y que en su trayectoria profesional tenían experiencia e incluso habían publicado artículos y libros sobre la aplicación de estrategias que posteriormente a alto nivel se plasmaron en el manifiesto ágil.

– Kent Beck: Americano. Creador de la metodología de programación extrema y de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development). Coautor de JUnit. Promotor de la reunión que dio lugar a la creación de manifiesto ágil para el desarrollo de software.

– Mike Beedle: Americano. Ha sido uno de los pioneros en la aplicación de Scrum (desde 1995) en proyectos de desarrollo de software en diferentes organizaciones y tipos de sistemas (en cuanto al proceso o procesos de negocio que tratan de informatizar).

– Arie van Bennekum: Holandés. Jefe de proyectos y consultor especializado en la metodología DSDM (método de desarrollo de sistemas dinámicos), representó al DSDM Consortium en la reunión.

– Alistair Cockburn: Americano. Creador de la familia de metodologías Crystal. Contribuyó a la expansión de la utilización de los casos de uso con la definición que hizo de los mismos en el libro “Escribir casos de uso efectivos” publicado en el año 2000, propiciando la generalización de su uso para describir el comportamiento de los requisitos software y de los procesos de negocio (a más alto nivel). La creación del concepto de caso de uso es bastante anterior, del año 1986 y fue realizada por el sueco Ivar Jacobson

– Ward Cunningham: Americano. Howard G. Cunningham fue el creador de la primera solución Wiki (WikiWikiWeb) y se considera un pionero tanto en la aplicación de programación extrema como en la utilización de patrones de diseño.

– Martin Fowler: Americano. Especialista en procesos de refactorización de software, programación orientada a objetos, UML y programación extrema. Hizo popular el uso del término “inyección de dependencias”.

– James Grenning: Americano. Especialista en sistemas empotrados. Fue uno de los pioneros en desarrollo de proyectos bajo la metodología de programación extrema. Experto en TDD (Test-driven Development). Ha sido el creador de la técnica de estimación Planning Poker.

– Jim Highsmith: Americano. James A. Highsmith III. Ingeniero de software experimentado que ha participado en proyectos de desarrollo de software en muchos países del mundo. En el año 1999 publicó el libro “Adaptative Software Development” donde puso de manifiesto la naturaleza adaptativa de los proyectos de desarrollo de software. Se ha especializado en la consultoría de proyectos que se realizan en entornos inestables y con una complejidad creciente.

– Andrew Hunt: Americano. Desarrollador de software con gran experiencia. Publicó junto a Dave Thomas en el año 1999 el libro “The Pragmatic Programmer”, en el que realizó una definición de lo que consideraban un programador práctico o pragmático:

– Early adopter.
– Curioso.
– Pensador crítico.
– Realista.
– Aprendiz de todo, maestro de nada.

Fue uno de los introductores en occidente de la programación en Ruby, mediante la publicación en el año 2000 del libro “Programming Ruby: A Pragmatic Programmer’s Guide”.

– Ron Jeffries: Considerado junto a Kent Beck y Ward Cunningham como uno de los creadores de la programación extrema. Participó junto a Beck en el proyecto de 1996 en Chrysler que dio lugar a este concepto.

– Brian Marick: Americano. Especialista en realización de tareas de testing. En el año 1995 publicó uno de sus libros más conocidos: “The Craft of Software Testing: Subsystem Testing Including Object-based and Object-oriented Testing”. Experto en Ruby.

– Robert C. Martin: Americano. Robert Cecil Martin (Uncle Bob). Dedicado a tareas de desarrollo de software desde 1970. Especialista en programación orientada a objetos sobre todo en el área de patrones de diseño.

– Steve Mellor: Americano. Especialista en sistemas empotrados, programación orientada a objetos y MDA (Model Driven Architecture). Creador junto a Sally Shlaer del método Shlaer-Mellor que es uno de los métodos de análisis y diseño orientado a objetos que surgió a finales de la década de los ochenta como respuesta a las principales problemáticas que presentaba el análisis y diseño estructurado, entre las cuales destacaban la complejidad de los diseños estructurados y la dificultad de mantener tanto su documentación de análisis como de diseño.

– Jon Kern: Americano. Inició su carrera profesional en sistemas empotrados en el área militar. Considerado como uno de los pioneros en la aplicación de la programación orientada a objetos. Especialista en programación Java y en MDA.

– Ken Schwaber y Jeff Sutherland: Americanos. Creadores de la metodología Scrum.

– Dave Thomas: Inglés. Autor junto a Andrew Hunt del libro “The Pragmatic Programmer”. También junto al mismo autor se considera uno de los introductores de Ruby en occidente.

La metodología de programación extrema fue introducida por el americano Kent Beck (autor también de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development) y coautor de JUnit) en el año 1999, aunque empezó a trabajar en la misma años antes, concretamente desde el año 1996 cuando fue contratado por Chrysler Corporation, para intentar sacar adelante una aplicación para nóminas que hasta entonces tenía importantes problemas en el desarrollo. Cuando empezó a trabajar en el proyecto, detectó una serie de aspectos en el proceso de desarrollo que debían cambiar, aplicando para ello una serie de estrategias, muchas de ellas basadas en buenas prácticas ya contempladas y utilizadas.

La programación extrema se sitúa en una posición diferente a los ciclos de vida tradicionales. Ya no se trata de requisitos que se cierran en etapas tempranas del desarrollo y que constituyen el contrato de lo que posteriormente se va a desarrollar (y que los usuarios no ven hasta mucho después) sino de requisitos que están vivos y que son modificables a lo largo del ciclo de vida.

La programación extrema se centra en cinco principios:

– Simplicidad: Conforme en el proceso de construcción un sistema va creciendo paulatinamente (aplicable también a mantenimientos sobre sistemas ya construidos), la complejidad del código va creciendo de manera proporcional (o incluso exponencial en función del tamaño del proyecto y del número de personas que participen en el proceso).

Mediante la refactorización, se intenta mantener el código en unas condiciones donde la complejidad esté controlada y facilite la escalabilidad del sistema. Esto requiere disciplina y creer que esta metodología produce resultados ya que resulta complicado tomar la decisión de tocar código que ya funciona (esto va en contra de una de las máximas de la programación que consiste en que no toques algo que funciona, aunque también es cierto que la misma viene derivada de las malas experiencias provocadas por la crisis del software).

La integración continua resulta esencial en esta metodología, ya que ofrece la oportunidad de probar con una cierta regularidad la integración de los componentes, de manera que este tipo de problemas se puede detectar lo antes posible.

El control de la calidad del código se complementa con otras estrategias como por ejemplo el intento de que el mismo sea lo más autocomentado posible (sin prescindir de comentarios cuando sean necesarios). ¿Por qué la metodología prioriza la autodocumentación? Como el proyecto es algo que está vivo, el código se modifica con cierta frecuencia (sobre todo en el proceso de construcción), ¿por qué preocuparse en comentar un código que tal vez tenga que modificar muy pronto ya sea por una modificación funcional, por una corrección o por una refactorización? A esto hay que añadirle el peligro de que empiecen a quedarse atrás comentarios que no se han eliminado y que no se correspondan con la realidad del código. Si el código está autodocumentado evoluciona de la misma manera que lo hace el proyecto.

Para esta metodología lo más importante del proceso de desarrollo de software es el código, la base para esto tiene un razonamiento simple, sin código no hay aplicación. Se considera que una aplicación que funciona según las necesidades del cliente tiene mucho más peso que el hecho de que esté documentada al detalle.

Para sostener esta afirmación en sistemas de un cierto tamaño es fundamental un código de mucha calidad. De no ser así, el cambio de un equipo de desarrollo por otro puede provocar un riesgo importante para conseguir una continuidad en el mantenimiento del proyecto ya que se estará caminando por un terreno lleno de trampas y con poca luminosidad.

– Comunicación: Fluida y continua. Para ello se programa por parejas (pair-programming, un ordenador, dos personas) y los usuarios designados por el cliente forman parte del equipo de desarrollo (se eliminan fronteras). Pero la comunicación va más allá de eso, un código comentado (autodocumentado) y con pruebas unitarias definidas expresa información para la comprensión del mismo, es como una caja del tiempo o un mensaje en una botella y que será muy útil cuando se tengan que realizar modificaciones.

Algunos de los críticos de esta metodología comentan que la tendencia de los programadores a considerar el código desarrollado como propio dificulta el proceso de comunicación ya que cada cual considera que sus opiniones y decisiones son y han sido las mejores, que su código es difícilmente superable (o por lo menos que era complicado hacerlo mejor en el tiempo que se ha dispuesto para desarrollarlo) y además no se suelen aceptar de buen grado las correcciones (sobre todo si están relacionadas con la calidad).

Para resolver ese inconveniente la programación extrema considera que el código es colectivo, no hay parcelas, de manera que cualquier integrante del equipo de proyecto puede realizar contribuciones a cualquier parte del mismo.

Las pruebas unitarias resultan esenciales, ya que permiten automatizar la revisión del funcionamiento de cada módulo y así tener la posibilidad de realizar este tipo de tareas con frecuencia. Hay que tener en cuenta también que el código está en continua evolución por lo que las pruebas de regresión cobran importancia. El objetivo es detectar posibles errores lo antes posible. La detección tardía de errores es más costosa y su corrección además tiende a ensuciar el código (cuando el tiempo aprieta lo importante es apagar el fuego).

Aunque no es obligatorio, se recomienda incluso que las pruebas unitarias de cada componente estén construidas antes de desarrollarlo.

Otro aspecto característico de la metodología son las reuniones diarias, que se realizan de pie y en círculo (stand-up meetings) y que tienen una duración aproximada de quince minutos. En las mismas se habla sobre el estado actual del proyecto y sobre contingencias, problemáticas o dudas que se produzcan en el mismo.

Para favorecer la comunicación se aconseja que todo el equipo de trabajo se encuentre en la misma ubicación física y en entornos despejados.

– Retroalimentación: La participación y proximidad de los usuarios permite resolver dudas casi de forma instantánea, pueden ver funcionalidades concretas construidas parcialmente y opinar sobre ellas. Se comparten opiniones sobre cuál puede ser la mejor solución (es importante lo funcional pero hay que equilibrar lo que se quiere con la complejidad de realizarlo, como dijo Voltaire, lo perfecto es enemigo de lo bueno)

El desarrollo iterativo incremental permite que en cada evolución el usuario pueda expresar su opinión sobre los resultados obtenidos y si es necesario corregir algo, planificarlo para la siguiente o próximas iteraciones.

– Coraje: Optar por esta metodología no es sencillo por muchos factores, por muchos interrogantes. ¿Es sencillo admitir que se programe por parejas?, es decir, ¿puede todo el mundo entender que en cada momento uno toque el teclado y el otro mire?, ¿se puede comprender que esta estrategia no tiene por qué afectar a la productividad?.

La programación en parejas tiene una serie de ventajas:

Las decisiones en la codificación no son algo unilateral de la persona que programa el componente (los arquitectos o analistas orgánicos no pueden llegar a todo el detalle de la programación, ya que ellos determinan el armazón de la aplicación que librerías utilizar, su división en capas, etc…, es decir, establecen el marco general).

El código es revisado en tiempo real, disminuyendo la probabilidad de error e incrementando la calidad del código.

Pero no es solo lo anterior, ¿puede ser admisible que se retoque software que ya funciona con el objeto de mejorar su calidad (simplicidad)?, ¿se puede vivir en un proyecto donde los requisitos están siempre en el aire?, ¿es sostenible un proyecto orientado a entregas continuas cada poco tiempo donde el cumplimiento de los plazos resulta de gran importancia?.

Sobre esto último algunos de los críticos con la metodología consideran que el equipo de trabajo está vendido a las entregas y que al haber muchas y frecuentes, los errores en la planificación provocarán numerosos picos de trabajo con el consiguiente overtime para los distintos integrantes del equipo de proyecto.

Sin embargo los defensores sostienen que el mismo Kent Beck considera que es necesario evitar el cansancio de los componentes del equipo de proyecto, debiéndose respetar su jornada laboral, situándose esta en cuarenta horas semanales. De hecho considera que no se debe haber overtime dos semanas consecutivas. Aplica por tanto el principio de responsabilidad en el sentido de que hay que tener disciplina con las entregas pero que eso no puede estar por encima de un continuo sobreesfuerzo de los integrantes del equipo de trabajo. ¿Por qué defiende esto? Pues porque los programadores cansados escriben código de peor calidad y además son menos productivos.

– Respeto: Algo complicado de encontrar en los proyectos de desarrollo de software y en un mundo tan ombliguista como es este. Se basa en el hecho de que todos los participantes en el equipo de proyecto suman y que es importante que se tenga en cuenta que para que todo vaya bien, todos tienen que dar lo mejor de sí y para que esto se pueda producir hay que crear un ambiente que lo propicie. Las críticas deben ser constructivas, siempre para mejorar, siempre para ir hacia adelante. Es importante que se tenga en cuenta que para que el barco vaya hacia adelante todos tienen que remar y que si se hunde se hunden todos.

Por otro lado cada participante debe asumir su responsabilidad, cada cual tiene su rol y debe entender que tras él hay una serie de tareas que se tienen que realizar, gustén más o gusten menos.

En el siguiente artículo sobre este tema se tratará sobre el ciclo de vida/metodología de la programación extrema.