¿QUÉ ES TDD? (Desarrollo digido por Tests)

TDD es una técnica de diseño e implementación de software que se centra en tres pilares principales:

• La implementación de las funciones justas que el cliente precisa.
• Minimizar errores que puedan llegar a la fase de producción.
• Producción de software modulable, reutilizable y preparado para el cambio.

TDD es la respuesta a las preguntas: ¿Cómo lo hago?, ¿Por dónde empiezo?, ¿Cómo sé qué es lo que hay que implementar y lo que no?, ¿Cómo sé que lo nuevo que desarrollo no rompe funcionalidad que ya está implementada?

¿Por qué utilizar TDD?

• La calidad del software aumenta.
• Desvincular el factor humano a las pruebas, al automatizar las mismas, cada una de ellas determina si se ejecutó con éxito o no.
• La automatización de las pruebas, implica una disminución del costo de las mismas, no solo porque se ejecuten rápidamente, sino además porque las podemos programar para que se ejecuten sin intervención humana.
• Código altamente reutilizable.
• Facilita el trabajo en equipo.
• Aumenta la confianza entre los compañeros.
• Evita sobrediseñar la aplicación, al escribir el test antes que el código.
• Si se revisa una aplicación desarrollada mediante TDD, ayuda a entender qué misión cumple cada pieza del puzzle.

El algoritmo de TDD tiene tres pasos:

• Escribir la especificación del requisito. Una vez se tiene claro el requisito, se expresa en forma de código. Lo escribe el propio desarrollador, de esta forma se consigue que él mismo escriba las propias pruebas.
• Implementar el código según dicho ejemplo. Una vez se tiene el ejemplo escrito, se escribe el código necesario para que se cumpla, para que el este pase correctamente.
• Refactorizar para eliminar duplicidades y hacer mejoras. Según Martin Fowler, refactorizar es modificar el diseño sin alterar su comportamiento.

Se puede utilizar TDD tanto en un proyecto grande como en uno pequeño. Un proyecto grande no es más que un conjunto de subproyectos pequeños. Lo importante es saber dividir y priorizar.

Tipos de tests:

• Test de aceptación. Es un test que permite comprobar que el software cumple con un requisito de negocio. Es un ejemplo escrito con el lenguaje del cliente pero que puede ser ejecutado por la máquina.
• Test funcionales. Comprueban alguna funcionalidad con valor de negocio. Un test funcional es un subconjunto de los tests de aceptación.
• Test de sistema. Se trata de un test que puede ir, incluso, de extremo a extremo de la aplicación o del sistema. Se habla de sistema porque es un término más general que aplicación. Los tests de sistema son muy frágiles porque cualquier cambio de las partes que componen el sistema, puede romperlos. No se recomienda escribir muchos por su fragilidad.
• Test unitarios. Son los test más importantes para los que usan TDD. Cada test unitario debe ser:
  • Atómico. Prueba la mínima cantidad de funcionalidad posible.
  • No puede depender de otros test para producir un resultado satisfactorio.
  • No altera el estado del sistema. Se puede ejecutar 1 ó 40 veces y el resultado será el mismo.
  • Rápido. Se ejecutan un gran número de tests cada pocos minutos. Si son lentos el resultado será improductivo.
  • Si no cumple estas premisas entonces no es un test unitario.

También veremos que se usa el acrónimo F.I.R.S.T., que viene a querer decir: Fast, Independent, Repeatable, Small y Transparent.

• Test de Integración. Son necesarios para encajar en el hueco entre los tests unitarios y los tests de sistema. Como su nombre indica, integración significa que ayuda a unir distintas partes del sistema. Es el complemento a los tests unitarios, donde habíamos “falseado” el acceso a datos para limitarnos a trabajar con la lógica de manera aislada.

Los tests más utilizados en TDD son los tests unitarios, de integración y de aceptación.

Los factores que limitan la implementación de TDD son:

• Incrementan el tiempo de desarrollo. El uso de TDD disminuye el número de errores y por lo tanto se consigue una mejor calidad. Por lo que se puede llegar a reducir el tiempo de desarrollo.
• Poca experiencia en TDD.
• Habilidades insuficientes en testing por parte de los desarrolladores.
• Insuficiente apego al protocolo de TDD por parte de los desarrolladores.
• Limitaciones en el dominio de las herramientas específicas de TDD.

Para saber más sobre cómo Sogeti puede ayudarle en el desarrollo proyectos IT, haga clic aquí.

Más información:

José Antonio González Romera es Técnico Superior en Desarrollo de aplicaciones informáticas, MCT Sharepoint Developer 2010 y MCPD Asp.Net Framework 3.5. Trabaja como informático desde el año 1999 y se incorporó a Sogeti en Abril de 2006 donde desarrolla aplicaciones para clientes de diversos sectores como sector público, museos, banca o aeronáutica.