UNIVERSIDAD DE OTAVALO
AUDITORIA Y
EVALUACIÓN DE SOFTWARE
Tema
TDD – Test Driven Development
Grupo 1
Cacuango Danny 1724574676
Guerrero Bryan 1751541135
Fernández Bryon 1723968234
Docente
Msc. Mayela Delgado
Periodo Académico
Abril- Julio
Contenido
Desarrollo................................................................................................................................................................3
¿Qué es el TDD?..................................................................................................................................................3
Objetivos del TDD..............................................................................................................................................4
Minimizar el número de bugs..........................................................................................................................4
Implementar las funcionalidades.....................................................................................................................4
Producir software modular,.............................................................................................................................4
Ciclo TDD...........................................................................................................................................................7
Escribir una prueba..........................................................................................................................................8
Verificación de la prueba.................................................................................................................................8
Refactorización................................................................................................................................................8
Actualización de requisitos.............................................................................................................................9
QUE ES EL UTDD?..........................................................................................................................................9
CICLO UTDD....................................................................................................................................................9
DEFINICIÓN DE BDD, ATDD, STDD, NDD...............................................................................................11
ATDD............................................................................................................................................................11
STDD.............................................................................................................................................................12
NDD..............................................................................................................................................................13
Tipos de pruebas y su automatización...........................................................................................................14
Pruebas de integración:.................................................................................................................................15
Buenas prácticas en TDD................................................................................................................................15
Refactoring.......................................................................................................................................................16
Conclusiones.........................................................................................................................................................16
Bibliografía...........................................................................................................................................................17
Introducción
Test-Driven Development1 (TDD) es una práctica iterativa de diseño de software orientado a
objetos, que fue presentada2 por Kent Beck y Ward Cunningham como parte de Extreme
Programming3 (XP) en [1].
Básicamente, incluye tres sub-prácticas:
• Automatización: las pruebas del programa deben ser hechas en código, y con la sola corrida
del código de pruebas debemos saber si lo que estamos probando funciona bien o mal.
• Test-First: las pruebas se escriben antes del propio código a probar.
• Refactorización4 posterior: para mantener la calidad del diseño, se cambia el diseño sin
cambiar la funcionalidad, manteniendo las pruebas como reaseguro
En castellano, “Desarrollo guiado por las pruebas”. En adelante figurará como TDD, su sigla
en inglés.
De todas maneras, no es una práctica totalmente nueva. Se han encontrado evidencias del uso
esporádico de TDD en la década de 1960, aunque no se le hubiese dado un nombre y un
alcance metodológico.
En castellano, “Programación extrema”. En adelante figurará como XP, su sigla en inglés.
Hemos usado el término “refactorización” como traducción del término inglés “refactoring”,
que se analiza luego en la sección “Prácticas relacionadas” de este trabajo.
En los tres casos en que el diagrama dice “correr pruebas” se refiere a todas las pruebas
generadas hasta el momento. Así, el conjunto de pruebas crece en forma incremental y sirve
como pruebas de regresión ante agregados futuros.
Desarrollo
¿Qué es el TDD?
Test-Driven development (TDD) es una práctica de programación que implica el
desarrollo de pequeñas piezas de código basándose en test cases escritos con anterioridad. ¿Y
esto que quiere decir? Quiere decir que el desarrollador escribe los test cases antes de escribir
el código. El tipo de pruebas (test cases) que hace el desarrollador suelen ser unitarias y
automatizadas.
Buscando técnicas para hacer que desarrollar software sea cada vez más sencillo y no
más complejo estoy últimamente interesado con las aproximaciones TDD
El Desarrollo Dirigido por Tests (Test Driven Development o TDD) es una técnica para
diseñar software que se centra en tres pilares fundamentales:
Objetivos del TDD
El propósito de esta técnica tiene los siguientes 3 objetivos básicos:
Minimizar el número de bugs: Mientras más bugs salgan menos rentable es el proyecto,
porque corregir los bugs es tiempo que se puede invertir mejor en otras tareas. Si no hay bugs
se puede conseguir una mayor rentabilidad de la aplicación.
Implementar las funcionalidades justas que el cliente necesita: Es muy común que cuando
se explican los requisitos de una aplicación o las especificaciones en la fase de análisis y
diseño se esboza una aplicación, y el diseñador por su experiencia con funcionalidades
pensando que van a ser útiles para la aplicación, para el cliente o para otros componentes. Sin
embargo casi el 95% de esas funcionalidades extras no se usan en ninguna parte de la
aplicación, eso implica tiempo invertido desarrollando algo que no ha llegado a nada. El
objetivo de TDD es eliminar ese código innecesario y esas funcionalidades que no ha pedido
el cliente, con lo cual redunda en eficiencia, tanto en el trabajo y como en la rentabilidad de la
aplicación.
Producir software modular, altamente reutilizable y preparado para el cambio: Esto es
realmente más técnica, porque con buenos hábitos de programación siempre se logra que el
proyecto sea modular y reutilizable. Prepararlo para el cambio es una característica que no se
consigue siempre y que con TDD si, ya que muchas veces cuando se tiene que cambiar la
funcionalidad de la aplicación se tiene que refactorizar código ajeno, trabajar con código
complicado, entre otras cosas; en cambio con TDD se tiene la confianza de que cuando se
haga cambios no se van a estropear las funcionalidades que ya se tienen.
Cunado utilizamos la técnica de TDD nos ahora mucho tiempo y nos garantiza una
prueba de calidad con menores errores y se tiene la confianza de que cuando se haga un
cambio no se van a estropear las funcionalidades que se tiene, ya que TDD realiza prueba de
errores y nos permite modificar códigos que no son necesarios en el software.
Test-driven development o Desarrollo guiado por pruebas de software, es un
procedimiento muy habitual entre los seguidores de metodologías ágiles. Se basa en un
desarrollo de pruebas a través de las cuales debe pasar el código, si está bien implementado,
se continúa creando código enfocado hacia la siguiente prueba, sino, se configura hasta que
pase la prueba y podamos ir a la siguiente fase. En este artículo vais a encontrar 14 beneficios
de TDD.
1. Usando procesos TDD evitamos escribir código innecesario. En muchas ocasiones un
programador crea más código del que necesita. Usando TDD, vas solucionando pequeñas
tareas, superando test concretos, que nos ayudan a optimizar el tiempo y ser mucho más
concretos durante la creación.
2. Feedback de API. Gracias a la rápida respuesta sobre la calidad del código y los
múltiples tests que nos ofrece TDD, el flujo de información es mayor.
3. Gran cantidad de documentación. Durante el proceso de creación del código, vamos
resolviendo dudas y superando trabajos que a la larga, nos proporcionan una preciada
documentación sobre todo lo que vamos implementando.
4. Diseño emergente. Al igual que la creación del codigo, el diseño es evolutivo y se
puede ir modificando a la vez que se va desarrollando el código. De forma que no es
necesario crear un diseño completo desde el principio.
5. Interface independiente. El código no tiene por qué influir al diseño, si desde un
principio ambos conocen los requisitos
6. Mejora la comunicación. Puesto que los problemas llegan en cortos periodos de
tiempo, fomenta la comunicación entre el equipo para poder solventarlos.
7. Mayor tranquilidad. Al seguir el proceso de TDD, sabes que al finalizar el trabajo, el
código será puro, claro y limpio.
8. Refactorización. Después de encontrar un problema, pasamos al proceso de
refactorización del mismo, de forma que no tenemos que esperar a tener el código finalizado
para poder llevar a cabo esta tarea, sino que el código se va reescribiendo a medida que se
detectan errores.
9. Depuración. TDD es la mejor forma para detectar los fallos, si aparece uno y
modificamos el código hasta que pase el test, lo vamos depurando poco a poco y obtenemos
un código limpio.
10. Escalabilidad. A medida que el proyecto avanza, el código se hace más complejo, y el
lanzamiento al mercado más próximo. TDD permite evaluar en qué punto nos encontramos
en cada momento.
11. Aprender. Puesto que en TDD el equipo trabaja junto para resolver los problemas, el
crecimiento individual también es mayor.
12. Satisfacción del cliente. En todo momento, los tests están pensados desde el punto de
vista del cliente, por lo tanto el producto estará totalmente enfocado a su satisfacción.
13. Desarrollo ágil. Un flujo continuo de tareas, análisis y correcciones es lo que define la
metodología ágil. TDD cuenta con todos los requisitos para serlo.
14. Mejor integración con terceros. Al llevar un minucioso seguimiento de las tareas,
reducimos los costes y el tiempo.
Ciclo TDD.
Ilustración 1Introducción Al Desarrollo Guiado Por Pruebas
Escribir una prueba
Luego escribiremos una prueba teniendo en cuenta el requisito de origen que hemos
seleccionado. Antes de comenzar a trabajar en ella, es imprescindible ser conscientes de lo
que se nos está solicitando. Habrá que valorar requisitos y especificaciones antes de elegir
una prueba en concreto.
Verificación de la prueba
Después verificamos que la prueba es errónea, llevamos a cabo la escritura de la
implementación de una forma simplificada (siempre la más fácil posible) y ejecutamos de
forma automática las pruebas. Ahora el sistema automatizará el proceso para mayor
satisfacción.
Refactorización
Como decíamos antes, tendremos que eliminar el código duplicado que haya quedado y
limpiarlo todo para dejarlo lo más suave posible. En este caso lo que necesitamos
implementar es la refactorización. Iremos borrando y probando hasta dar con la versión
adecuada.
Actualización de requisitos
Acabamos con la necesaria actualización de los requisitos. El que ya se haya
implementado se eliminará y, si nos hemos encontrado con alguno extra, lo añadiremos,
puesto que el trabajo posiblemente esté lejos de haber terminado. Cuanto más de la mano
tengamos este sistema, más nos aseguraremos de que todo rendirá de manera fluida a la hora
de la verdad.
QUE ES EL UTDD?
UTDD o Desarrollo guiado por pruebas unitarias es una forma de comprobar el correcto
funcionamiento de una unidad de código. Por ejemplo en diseño estructurado o en diseño
funcional una función o un procedimiento.
Esto sirve para asegurar que cada unidad funcione correctamente y eficientemente por
separado. Además de verificar que el código hace lo que tiene que hacer, verificamos que sea
correcto el nombre, los nombres y tipos de los parámetros, el tipo de lo que se devuelve, que
si el estado inicial es válido entonces el estado final es válido.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo,
de forma que cada caso sea independiente del resto. Luego, con las Pruebas de Integración, se
podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
CICLO UTDD.
Elegir un requisito: Se elige de una lista el requisito que se cree que nos dará mayor
conocimiento del problema y que a la vez sea fácilmente implementarle.
Escribir una prueba: Se comienza escribiendo una prueba para el requisito. Para ello el
programador debe entender claramente las especificaciones y los requisitos de la
funcionalidad que está por implementar. Este paso fuerza al programador a tomar la
perspectiva de un cliente considerando el código a través de sus interfaces.
Verificar que la prueba falla: Si la prueba no falla es porque el requisito ya estaba
implementado o porque la prueba es errónea.
Escribir la implementación: Escribir el código más sencillo que haga que la prueba
funcione..
Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona
correctamente.
Eliminación de duplicación: El paso final es la refactorización, que se utilizará
principalmente para eliminar código duplicado. Se hace un pequeño cambio cada vez y luego
se corren las pruebas hasta que funcionen.
Actualización de la lista de requisitos: Se actualiza la lista de requisitos tachando el
requisito implementado. Asimismo se agregan requisitos que se hayan visto como necesarios
durante este ciclo y se agregan requisitos de diseño.
Tener un único repositorio universal de pruebas facilita complementar TDD con otra
práctica recomendada por los procesos ágiles de desarrollo, la "Integración Continua".
Integrar continuamente nuestro trabajo con el del resto del equipo de desarrollo permite
ejecutar toda batería de pruebas y así descubrir si nuestra última versión es compatible con el
resto del sistema. Es recomendable y menos costoso corregir pequeños problemas cada pocas
horas que enfrentarse a problemas enormes cerca de la fecha de entrega fijada.
DEFINICIÓN DE BDD, ATDD, STDD, NDD.
BDD.
BDD es un conjunto de prácticas que buscan mejorar la comunicación de los
requerimientos y expresar mediante ejemplos el diseño de un software. Da soporte directo a
los valores ágiles de colaboración con el cliente y respuesta al cambio, ya que ayuda a crear
un lenguaje común entre el equipo que desarrolla y las personas que definen los
requerimientos del negocio, permitiendo al equipo enfocarse en el desarrollo de software que
verdaderamente cumpla las necesidades del cliente, y quedando las especificaciones en
formato ejecutable, lo que resulta en una matriz de pruebas automatizadas que ayudan a
detectar regresiones y fallas, permitiendo al equipo escribir código limpio y adaptable a
cambios en el tiempo.
ATDD.
Es una práctica en la que todo el equipo, destacando, e incluyendo, a los usuarios y/o al
product owner, desarrolladores y tester, analiza conjuntamente los criterios de aceptación,
antes de que comience el desarrollo.
Aquí hay dos prácticas claves para estar ante un ATDD, importantes de conocer para
diferenciar el ATDD de las tradicionales pruebas de aceptación:
– Antes de implementar una necesidad, requisito, historia de usuario, etc., los miembros
del equipo (usuarios, o product owners, desarrolladores, tester, etc.) colaboran para crear
escenarios, ejemplos, de cómo se comportará dicha necesidad.
– Después de implementar una necesidad, el equipo convierte esos escenarios en pruebas
de aceptación automatizadas. Estas pruebas de aceptación típicamente se automatizan usando
Selenium o similares, “frameworks” como Cucumber “pegan” las diferentes pruebas, etc.
STDD.
Story Test-Driven Development (STDD) es una extensión de Test-Driven Development
(TDD). Mientras que TDD se enfoca más en el nivel de prueba de la unidad, STDD comienza
con pruebas de aceptación de nivel superior. STDD tiene los siguientes componentes:
Especificación del sistema: este es el documento que describe cómo se espera que el
sistema se comporte. Está escrito en el idioma del cliente y puede ser manejable por el
cliente. Esto significa que debería poder leerlo o modificarlo fácilmente. Usamos HTML
como el formato para describir la especificación del sistema.
Accesorio de prueba de aceptación: el dispositivo lee en la especificación y ejecuta el
sistema para verificar si se cumple con la especificación.
Casos de prueba unitaria: estas son las pruebas especificadas por los desarrolladores. Los
desarrolladores usan casos de pruebas unitarias para guiar el desarrollo y asegurarse de que el
programa se ejecute como se espera.
Resultados de la prueba de historia: informa el estado de las pruebas de aceptación.
El proceso STDD se puede describir de la siguiente manera:
*El cliente escribe las especificaciones del sistema.
*El desarrollador escribe una clase de esqueleto para el accesorio de prueba. Llamamos a
esto la "especificación de enfoque".
*Ejecute la prueba de aceptación. Debido a que el sistema aún no está implementado, el
resultado de la prueba mostrará muchos errores.
*Escriba una prueba unitaria para un subconjunto del sistema que se aborda en la
especificación de enfoque.
*Ejecute la prueba unitaria. Fallará porque el sistema aún no está implementado.
*Implemente el sistema para que pase la prueba de la unidad.
*Re factorice el código y la prueba unitaria para eliminar todo el código redundante.
*Ejecute la prueba de aceptación. Parte de la prueba puede pasar porque parte del sistema
está implementado.
*Repita los pasos 5 a 8 hasta que se apruebe la prueba de aceptación para la
especificación de enfoque.
*Repita desde el paso 2. Elija otra especificación de enfoque hasta que se implementen
todas las especificaciones.
NDD.
En la ingeniería de software, la depuración de patos de goma o la protección de goma es
un método de depuración de código. El nombre es una referencia a una historia en el libro
The Pragmatic Programmer en la que un programador llevaría un pato de goma y depuraría
su código forzándose a sí mismo a explicarlo, línea por línea, al pato.
La técnica del patito de goma en realidad funciona y llega al mismo resultado de explicar
su problema a un compañero de trabajo o amigo. Pero lo veo como de corta duración y solo
aparece después de que ya haya escrito el código. Con NDD resuelve el mismo problema y
avanza más al comenzar antes en su proceso, agregar documentación a su código, agregar
pruebas antes de comenzar y puede usarse como referencia en una fecha posterior.
En lugar de hablar en voz alta en la oficina a un pato de goma y parecer un loco, escriba
su tarea dividiéndola en oraciones simples, de forma similar a una lista de verificación.
La técnica consiste en tener al que se le explica de viva voz el código fuente que está
dando los problemas, línea por línea, verbalizando lo que hace ese código y los motivos a los
que responde su existencia.
Tipos de pruebas y su automatización.
Pruebas unitarias: se encargan de probar una clase en concreto, testeando cada uno de sus
métodos y viendo si dados unos parámetros de entrada, la salida es la esperada.
Pruebas funcionales: como su propio nombre indican, prueban una funcionalidad
completa, donde pueden estar implicadas una o varias clases, la propia interfaz de usuario y,
en el caso del desarrollo web, llamada AJAX.
Pruebas de regresión: son aquellas pruebas cuyo objetivo es comprobar por qué ha
dejado de funcionar algo que ya funcionaba. El objetivo de las pruebas de regresión es no
tener que “volver atrás”.
Pruebas de aceptación: son pruebas funcionales, pero vistas directamente desde el
cliente. Digamos que son aquellas pruebas que demuestran al cliente que la funcionalidad
está terminada y funciona correctamente.
Pruebas de integración: conjunto de pruebas unitarias, funcionales, de regresión y/o de
aceptación que se realizan las probar el software. Incluye también comprobar que lo
programado por los diferentes desarrollados no “choca” entre sí y que funcionará en un
entorno real
Buenas prácticas en TDD.
Tener el código separado de los tests, en carpetas diferentes.
Los tests deben fallar la primera vez que son escritos.
Los nombres de los tests deben ir acorde con la intención, deben ser nombres expresivos.
Refactorizar para eliminar código duplicado después de pasar los tests.
Repetir las pruebas después de cada refactorización.
Solo se debe escribir nuevo código, cuando algún test falla. Cada test debe comprar un
nuevo comportamiento, o diferente.
Escribe primero el assert.
Minimiza los asserts en cada test.
Todos los tests deben ser pasados antes de escribir otro test.
Solo se refactoriza cuando todos los tests pasan.
Escribe el mínimo y simple código para pasar las pruebas.
No usar las dependencias entre tests. Los tests deben pasar en cualquier orden.
Los tests deben ser rápidos.
Refactoring.
Se usa a menudo para describir la modificación del código fuente sin cambiar su
comportamiento, lo que se conoce informalmente por limpiar el código
Conclusiones
Cunado utilizamos la técnica de TDD nos ahora mucho tiempo y nos garantiza una
prueba de calidad con menores errores y se tiene la confianza de que cuando se haga un
cambio no se van a estropear las funcionalidades que se tiene, ya que TDD realiza prueba de
errores y nos permite modificar códigos que no son necesarios en el software.
El utdd nos sirve para comprobar el diseño estructurado o en diseño funcional una
función o un procedimiento, con esto nos aseguramos que cada unidad funcione
correctamente y eficientemente por separado.
Bibliografía
Fontela, M. C. (2011). Estado del arte y tendencias en.
https://mondongorongo.wordpress.com/2015/01/10/principios-del-desarrollo-guiado-por-
pruebas/
https://unpocodejava.com/2010/06/08/%C2%BFque-es-el-desarrollo-dirigido-por-test-tdd/
http://www.softqanetwork.com/%C2%BFque-es-test-driven-development-tdd
https://openwebinars.net/blog/que-es-tdd-test-driven-development/
https://apiumhub.com/es/tech-blog-barcelona/beneficios-de-tdd/
http://blog.linkeit.com/tdd-ciclo-trabajo-test-driven-development-para-sap
