¿Qué es el desarrollo basado en pruebas (TDD)? Ejemplo

¿Qué es el desarrollo basado en pruebas (TDD)?

Desarrollo basado en pruebas (TDD) Es un enfoque de desarrollo de software en el que se desarrollan casos de prueba para especificar y validar lo que hará el código. En términos simples, primero se crean y prueban casos de prueba para cada funcionalidad y, si la prueba falla, se escribe el nuevo código para pasar la prueba y hacer que el código sea simple y libre de errores.

El desarrollo basado en pruebas comienza con el diseño y desarrollo de pruebas para cada pequeña funcionalidad de una aplicación. El marco TDD indica a los desarrolladores que escriban código nuevo solo si una prueba automatizada falla. Esto evita la duplicación de código. La forma completa de TDD es un desarrollo basado en pruebas.

Desarrollo impulsado por prueba

El concepto simple de TDD es escribir y corregir las pruebas fallidas antes de escribir código nuevo (antes del desarrollo). Esto ayuda a evitar la duplicación de código, ya que escribimos una pequeña cantidad de código a la vez para pasar las pruebas. (Las pruebas no son más que condiciones de requisitos que debemos probar para cumplirlas).

El desarrollo basado en pruebas es un proceso de desarrollo y ejecución de pruebas automatizadas antes del desarrollo real de la aplicación. Por lo tanto, TDD a veces también se denomina Prueba del primer desarrollo.

Cómo realizar la prueba TDD

Los siguientes pasos definen cómo realizar la prueba TDD,

  1. Añade una prueba.
  2. Ejecute todas las pruebas y vea si falla alguna prueba nueva.
  3. Escribe algún código.
  4. Ejecute pruebas y refactorice código.
  5. Repita.
Realizar prueba TDD
Cinco pasos del desarrollo basado en pruebas

El ciclo TDD define

  1. Escribe una prueba
  2. Hazlo funcionar.
  3. Cambie el código para corregirlo, es decir, refactorizar.
  4. Repita el proceso.

Algunas aclaraciones sobre TDD:

  • El enfoque TDD no se trata de "pruebas" ni de "diseño".
  • TDD no significa “escribir algunas de las pruebas y luego construir un sistema que pase las pruebas”.
  • TDD no significa "hacer muchas pruebas".

TDD vs. Pruebas tradicionales

A continuación se muestra la principal diferencia entre el desarrollo impulsado por pruebas y las pruebas tradicionales:

El enfoque TDD es principalmente una técnica de especificación que garantiza que el código fuente se pruebe exhaustivamente a nivel de confirmación.

  • Con las pruebas tradicionales, una prueba exitosa encuentra uno o más defectos. Es lo mismo que TDD. Cuando una prueba falla, usted ha progresado porque sabe que necesita resolver el problema.
  • TDD garantiza que su sistema realmente cumpla con los requisitos definidos para él. Ayuda a desarrollar su confianza en su sistema.
  • En TDD, la atención se centra más en el código de producción que verifica si las pruebas funcionarán correctamente. En las pruebas tradicionales, se presta más atención al diseño de casos de prueba. Si la prueba mostrará la ejecución adecuada o incorrecta de la aplicación para cumplir con los requisitos.
  • En TDD, logras una prueba de cobertura del 100%. Se prueba cada línea de código, a diferencia de las pruebas tradicionales.
  • La combinación de las pruebas tradicionales y TDD lleva a la importancia de probar el sistema en lugar de perfeccionarlo.
  • In Modelado ágil (AM), debes “probar con un propósito”. Debes saber por qué estás probando algo y en qué nivel es necesario probarlo.

¿Qué es la aceptación TDD y Developer TDD?

Hay dos niveles de TDD

  1. Aceptación TDD (ATDD): Con ATDD escribes una única prueba de aceptación. Esta prueba cumple con el requisito de la especificación o satisface el comportamiento del sistema. Después de eso, escriba suficiente código de producción/funcionalidad para cumplir con esa prueba de aceptación. La prueba de aceptación se centra en el comportamiento general del sistema. ATDD también era conocido como Desarrollo impulsado por el comportamiento (BDD).
  2. Desarrollador TDD: Con Developer TDD usted escribe una prueba de desarrollador único, es decir, una prueba unitaria y luego el código de producción suficiente para cumplir esa prueba. La prueba unitaria se centra en cada pequeña funcionalidad del sistema. El desarrollador TDD se llama simplemente como TDD.El objetivo principal de ATDD y TDD es especificar requisitos detallados y ejecutables para su solución justo a tiempo (JIT). JIT significa tener en cuenta sólo aquellos requisitos que son necesarios en el sistema. Así que aumente la eficiencia.

Aceptación TDD y Desarrollador TDD

Ampliación de TDD mediante el desarrollo ágil impulsado por modelos (AMDD)

TDD es muy bueno en especificaciones detalladas y validación. No logra pensar en cuestiones más importantes, como el diseño general, el uso del sistema o la interfaz de usuario. AMDD aborda los problemas de escalamiento ágil que TDD no aborda.

Por lo tanto, AMDD se utiliza para problemas mayores.

El ciclo de vida de AMDD

El ciclo de vida de AMDD

En el desarrollo basado en modelos (MDD), se crean modelos extensos antes de escribir el código fuente. ¿Cuáles a su vez tienen un enfoque ágil?

En la figura anterior, cada cuadro representa una actividad de desarrollo.

La visualización es uno de los procesos de TDD de predicción/imaginación de pruebas que se realizarán durante la primera semana del proyecto. El objetivo principal de la visualización es identificar el alcance del sistema y la arquitectura del mismo. Para que la visualización sea exitosa, se realizan requisitos de alto nivel y se modela la arquitectura.

Es el proceso en el que no se realiza una especificación detallada del software/sistema sino que se exploran los requisitos del software/sistema lo que define la estrategia general del proyecto.

Iteración 0: Visualización

Hay dos subactivaciones principales.

  1. Visualización de requisitos iniciales.Puede llevar varios días identificar los requisitos de alto nivel y el alcance del sistema. El objetivo principal es explorar el modelo de uso, el modelo de dominio inicial y el modelo de interfaz de usuario (UI).
  2. Inicial Archivisión estructural. También se necesitan varios días para identificar la arquitectura del sistema, lo que permite establecer las direcciones técnicas del proyecto. El objetivo principal es explorar los diagramas de tecnología, el flujo de la interfaz de usuario (UI), los modelos de dominio y los casos de cambio.

Modelado de iteración

Aquí el equipo debe planificar el trabajo que se realizará para cada iteración.

  • Se utiliza un proceso ágil para cada iteración, es decir, durante cada iteración, se agregará un nuevo elemento de trabajo con prioridad.
  • Se tendrán en cuenta los primeros trabajos de mayor prioridad. Los elementos de trabajo agregados se pueden cambiar de prioridad o eliminar de la pila de elementos en cualquier momento.
  • El equipo analiza cómo implementarán cada requisito. Para ello se utiliza el modelado.
  • El análisis y diseño del modelado se realiza para cada requisito que se va a implementar para esa iteración.

Asalto de modelos

Esto también se conoce como Modelado Justo a Tiempo.

  • Aquí, la sesión de modelado involucra a un equipo de 2/3 miembros que discuten temas en papel o pizarra.
  • Un miembro del equipo le pedirá a otro que modele con ellos. Esta sesión de modelado durará aproximadamente de 5 a 10 minutos. Donde los miembros del equipo se reúnen para compartir pizarra/papel.
  • Exploran problemas hasta que no encuentran la causa principal del problema. Justo a tiempo, si un miembro del equipo identifica el problema que quiere resolver, recibirá ayuda rápida de otros miembros del equipo.
  • Luego, otros miembros del grupo exploran el tema y luego todos continúan como antes. También se denomina modelado stand-up o sesiones de control de calidad del cliente.

Desarrollo basado en pruebas (TDD)

  • Promueve la prueba confirmatoria del código de su aplicación y la especificación detallada.
  • Tanto las pruebas de aceptación (requisitos detallados) como las pruebas de desarrollador (pruebas unitarias) son entradas para TDD.
  • TDD hace que el código sea más sencillo y claro. Permite al desarrollador mantener menos documentación.

Reseñas

  • Esto es opcional. Incluye inspecciones de códigos y revisiones de modelos.
  • Esto se puede hacer para cada iteración o para todo el proyecto.
  • Esta es una buena opción para dar retroalimentación para el proyecto.

Desarrollo basado en pruebas (TDD) vs. Desarrollo ágil impulsado por modelos (AMDD)

TDD AMDD
TDD acorta el ciclo de retroalimentación de programación AMDD acorta el ciclo de retroalimentación del modelado.
TDD es una especificación detallada AMDD funciona para problemas mayores
TDD promueve el desarrollo de código de alta calidad AMDD promueve una comunicación de alta calidad con las partes interesadas y los desarrolladores.
TDD habla con programadores AMDD habla con Business Analyst, partes interesadas y profesionales de datos.
TDD no orientado visualmente AMDD orientado visualmente
TDD tiene alcance limitado a trabajos de software AMDD tiene un amplio alcance que incluye a las partes interesadas. Implica trabajar hacia un entendimiento común
Ambos apoyan el desarrollo evolutivo. ---------------

Marcos TDD

Aquí está la lista de los mejores marcos de desarrollo impulsado por pruebas (TDD)

  1. junit
  2. TestNG
  3. csUnit y NUnit
  4. rspec

Ahora, aprendamos sobre el desarrollo basado en pruebas con el ejemplo.

Ejemplo de TDD

En este ejemplo de desarrollo basado en pruebas, definiremos una contraseña para la clase. Para esta clase, intentaremos satisfacer las siguientes condiciones.

Una condición para la aceptación de la contraseña:

  • La contraseña debe tener entre 5 y 10 caracteres.

Primero, en este ejemplo de TDD, escribimos el código que cumple con todos los requisitos anteriores.

Ejemplo de TDD

Escenario 1: Para ejecutar la prueba, creamos la clase PasswordValidator ();

Ejemplo de TDD

Ejecutaremos la clase anterior TestPassword ();

La salida es APROBADA como se muestra a continuación;

Salida:

Ejemplo de TDD

Escenario 2: Aquí podemos ver que en el método TestPasswordLength () no es necesario crear una instancia de la clase PasswordValidator. Instancia significa crear una objeto de clase para referirse a los miembros (variables/métodos) de esa clase.

Ejemplo de TDD

Eliminaremos la clase PasswordValidator pv = new PasswordValidator () del código. Podemos llamar al es válida () método directamente por Validador de contraseña. Es válido ("Abc123"). (Ver imagen abajo)

Entonces refactorizamos (cambiamos el código) como se muestra a continuación:

Ejemplo de TDD

Escenario 3: Después de refactorizar, la salida muestra un estado fallido (ver imagen a continuación). Esto se debe a que eliminamos la instancia. Así que no hay ninguna referencia a no estático Método es válida ().

Ejemplo de TDD

Por lo tanto, debemos cambiar este método agregando la palabra "estática" antes de booleano como booleano estático público isValid (contraseña de cadena). Refactorización de la clase PasswordValidator () para eliminar el error anterior y pasar la prueba.

Ejemplo de TDD

Salida:

Después de realizar cambios en la clase PassValidator (), si ejecutamos la prueba, la salida será APROBADA como se muestra a continuación.

Ejemplo de TDD

Ventajas de TDD

Las siguientes son las principales ventajas del desarrollo impulsado por pruebas en ingeniería de software:

Notificación temprana de errores.

  • Los desarrolladores prueban su código, pero en el mundo de las bases de datos, esto suele consistir en pruebas manuales o scripts únicos. Al utilizar TDD, con el tiempo crea un conjunto de pruebas automatizadas que usted y cualquier otro desarrollador pueden volver a ejecutar a voluntad.

Código mejor diseñado, más limpio y más extensible.

  • Ayuda a comprender cómo se utilizará el código y cómo interactúa con otros módulos.
  • Da como resultado una mejor decisión de diseño y un código más fácil de mantener.
  • TDD permite escribir código más pequeño con una sola responsabilidad en lugar de procedimientos monolíticos con múltiples responsabilidades. Esto hace que el código sea más sencillo de entender.
  • TDD también obliga a escribir solo código de producción para pasar pruebas basadas en los requisitos del usuario.

Confianza para refactorizar

  • Si refactoriza el código, puede haber posibilidades de que se produzcan roturas en el código. Entonces, al tener un conjunto de pruebas automatizadas, puedes corregir esas fallas antes del lanzamiento. Se dará una advertencia adecuada si se encuentran interrupciones cuando se utilizan pruebas automatizadas.
  • El uso de TDD debería dar como resultado un código más rápido y extensible con menos errores que se pueda actualizar con riesgos mínimos.

Bueno para el trabajo en equipo

  • En ausencia de algún miembro del equipo, otros miembros del equipo pueden retomar y trabajar en el código fácilmente. También ayuda a compartir conocimientos, lo que hace que el equipo sea más eficaz en general.

Bueno para los desarrolladores

  • Aunque los desarrolladores tienen que dedicar más tiempo a escribir casos de prueba de TDD, se necesita mucho menos tiempo para depurar y desarrollar nuevas funciones. Escribirás código más limpio y menos complicado.

Resum

  • TDD significa desarrollo basado en pruebas.
  • Significado de TDD: Es un proceso de modificación del código para pasar una prueba diseñada previamente.
  • Hace más énfasis en el código de producción que en el diseño de casos de prueba.
  • El desarrollo basado en pruebas es un proceso de modificación del código para pasar una prueba diseñada previamente.
  • In Ingeniería de Software, A veces se le conoce como "Prueba primero el desarrollo".
  • Las pruebas TDD incluyen refactorizar un código, es decir, cambiar/agregar una cierta cantidad de código al código existente sin afectar el comportamiento del código.
  • Cuando se utiliza la programación TDD, el código se vuelve más claro y sencillo de entender.