Habitualmente se suele describir la base del TDD como la combinación de dos prácticas:
(1) Desarrollar construyendo primero el código de las pruebas. Al contrario de la aproximación considerada más “tradicional”, en la que uno primero escribe el código del programa y después construye las pruebas necesarias para verificar que el programa funciona y resuelve lo que se pretendía, lo que se aborda primero es la traducción de los requisitos a pruebas (en inglés denominadas “unit tests”) que el código debe superar. De esa manera, el código que se crea primero es de la prueba, que es ejecutada automáticamente para validar si nuestro “código de producto” (el del producto que efectivamente queremos construir) es correcto. En la medida en que una de estas pruebas no es superada (lógicamente al iniciarse el desarrollo toda prueba “fallará” al no tener aún código de producto con el que superarla), identificamos que debemos construir nuevo código en nuestro producto para superar la prueba y de esa manera validar que estamos cumpliendo el requisito especificado.
(2) Refactorización / Limpieza de código. El objetivo de la práctica anterior es construir el código más simple posible que supere las pruebas que tenemos identificadas como traducción de los requisitos a una prueba automatizable. Esta prioridad hace que, una vez que nuestro código de producto supere todas las pruebas, sea necesaria una cierta refactorización y limpieza de código, para conseguir un producto software con un código más claro (por ejemplo eliminando trozos duplicados) y mejorando su calidad y eficiencia.
La práctica del desarrollo dirigido por pruebas, además de los beneficios inherentes a las metodologías ágiles (como un mejor control del foco de trabajo en cada momento) permite una traducción directa de los requisitos del producto a tareas concretas de programación, lo que además centra al programador en la visión de cómo los clientes utilizarán el producto a construir, convirtiendo dicha visión en pruebas automatizadas. Por otro lado, precisamente ese carácter de pruebas automatizadas es donde reside quizá la principal limitación del método, ya que a la hora de construir un producto digital hay determinado tipo de requisitos (por ejemplo algunos relativos al interfaz de usuario) que también debemos validar pero para los cuales es sensiblemente más complejo construir pruebas automatizadas.
Este artículo de Scott Ambler nos ofrece una perspectiva introductoria pero muy completa acerca del desarrollo dirigido por pruebas, que también contiene la referencia de diversas herramientas para ponerlo en práctica en diversos entornos de programación. En la siguiente entrada me centraré en varios recursos en castellano que igualmente podemos encontrar por la web sobre el Test-Driven Development.
(1) Desarrollar construyendo primero el código de las pruebas. Al contrario de la aproximación considerada más “tradicional”, en la que uno primero escribe el código del programa y después construye las pruebas necesarias para verificar que el programa funciona y resuelve lo que se pretendía, lo que se aborda primero es la traducción de los requisitos a pruebas (en inglés denominadas “unit tests”) que el código debe superar. De esa manera, el código que se crea primero es de la prueba, que es ejecutada automáticamente para validar si nuestro “código de producto” (el del producto que efectivamente queremos construir) es correcto. En la medida en que una de estas pruebas no es superada (lógicamente al iniciarse el desarrollo toda prueba “fallará” al no tener aún código de producto con el que superarla), identificamos que debemos construir nuevo código en nuestro producto para superar la prueba y de esa manera validar que estamos cumpliendo el requisito especificado.
(2) Refactorización / Limpieza de código. El objetivo de la práctica anterior es construir el código más simple posible que supere las pruebas que tenemos identificadas como traducción de los requisitos a una prueba automatizable. Esta prioridad hace que, una vez que nuestro código de producto supere todas las pruebas, sea necesaria una cierta refactorización y limpieza de código, para conseguir un producto software con un código más claro (por ejemplo eliminando trozos duplicados) y mejorando su calidad y eficiencia.
La práctica del desarrollo dirigido por pruebas, además de los beneficios inherentes a las metodologías ágiles (como un mejor control del foco de trabajo en cada momento) permite una traducción directa de los requisitos del producto a tareas concretas de programación, lo que además centra al programador en la visión de cómo los clientes utilizarán el producto a construir, convirtiendo dicha visión en pruebas automatizadas. Por otro lado, precisamente ese carácter de pruebas automatizadas es donde reside quizá la principal limitación del método, ya que a la hora de construir un producto digital hay determinado tipo de requisitos (por ejemplo algunos relativos al interfaz de usuario) que también debemos validar pero para los cuales es sensiblemente más complejo construir pruebas automatizadas.
Este artículo de Scott Ambler nos ofrece una perspectiva introductoria pero muy completa acerca del desarrollo dirigido por pruebas, que también contiene la referencia de diversas herramientas para ponerlo en práctica en diversos entornos de programación. En la siguiente entrada me centraré en varios recursos en castellano que igualmente podemos encontrar por la web sobre el Test-Driven Development.
No hay comentarios:
Publicar un comentario