El desarrollo y ejecución de test es una actividad fundamental en los proyectos de desarrollo de software y ayudan a mantener un código de calidad durante la vida de este. El caso concreto de los test unitarios representa la mejor alternativa para encontrar y corregir la mayoría de los errores de codificación. Aunque todos los tipos de test son importantes, este artículo está dedicado a especialmente a los test unitarios utilizando mocks y a la incorporación de los test en el proceso de desarrollo.
Desarrollo Dirigido por Test (Test Drive Development).
Según Ble Jurado C (2010), es una técnica de diseño e implementación de software incluida dentro de la metodóloga XP. TDD es una técnica para diseñar software que se centra en tres pilare fundamentales:
- La implementación de las funciones juntas que el cliente necesita y no mas
- La minimización del número de defectos que llegan al software en fase de producción.
- La producción del software modular, altamente reutilizable y preparado para el cambio.
Las Reglas de Test Drive Development (TDD)
Según Martin Robert C. (2009), una de las máximas autoridades en TDD, describe el proceso en base a tres simples reglas:
- No está permitido escribir ningún código de producción sin tener una prueba que falle.
- No está permitido escribir más código de prueba que el necesario para fallar (y no compilar es fallar).
- No está permitido escribir más código de producción que el necesario para pasar su prueba unitaria.
Esto significa que antes de poder escribir cualquier código, debemos pensar en una prueba apropiada para él. Pero por la regla número dos, tampoco podemos escribir mucho de dicha prueba. En realidad, debemos detenernos en el momento en que la prueba falla al compilar o falla un assert y comenzar a escribir código deproducción.
Ciclo de desarrollo de TDD
El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:
- El cliente escribe su historia de usuario.
- Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
- Se escoge el criterio de aceptación más simple y se traduce en una prueba
- Se comprueba que esta prueba falla.
- Se escribe el código que hace pasar la prueba.
- Se ejecutan todas las pruebas automatizadas.
- Se re factoriza y se limpia el código.
- Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
- Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.
Ventajas de usar TDD
La pregunta habitual cuando alguien te habla sobre TDD es ¿Porque es mejor hacer las pruebas antes que el código? Para responder a esta pregunta:
- tenemos que pensar en la forma que se aplica TDD. Por un lado si se implementa y después se realizan las pruebas estas suelen estar condicionadas a lo implementado, con lo que es fácil obviar pruebas u olvidar algunos casos de test.
- Por otro lado al realizar primero las pruebas se realiza un ejercicio previo de análisis, en profundidad, de los requisitos y de los diversos escenarios.
- Eliminando la mayor parte de variabilidad y encontrado aquellos aspectos más importantes o no contemplados en los requisitos.
- El hecho que además solo se implemente el código necesario para resolver un caso de prueba concreto, pasar la prueba, hace que el código creado sea el mínimo necesario, reduciendo redundancia y los típicos bloques de código de “por si a caso” que habitualmente se convierten en descritos en los requisitos.
- Obviamente la obtención de un buen resultado aplicando TDD depende de realizar un conjunto de pruebas unitarias que cubran todos los casos
Tips para el aprendizaje de DDT
A continuación comparto algunos tips que te ayudarán para el aprendizaje de TDD:
- Escribe muchas pruebas, tantas como puedas. Familiarizarse con el ritmo y las reglas de TDD.
- Comenzar con algo sencillo (pero no detenerse ahí).
- Ser persistente y no rendirse. para obtener los frutos, se debe primero poner el trabajo duro.
- Conforme se escriban más y más pruebas, se debe comenzar a organizarlas en suites y asegurarse que estas puedan ejecutarse de forma individual o colectiva, según sea necesario.
En Nuestra Presentación de explicacion del tema se con contó con el apoyo del siguiente material:
A continuacion se muestra una material brindado por el equipo ASP.NET en el cual observamos de manera muy explicita lo que es el TDD:
No hay comentarios:
Publicar un comentario