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

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

El concepto simple de TDD es escribir y corregir las pruebas fallidas antes de escribir nuevo código (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 necesitamos probar para cumplirlas).

El desarrollo basado en pruebas es un proceso de desarrollo y ejecución automatizada prueba antes del desarrollo real de la aplicación. Por lo tanto, TDD a veces también se denomina Test First Development.

En este tutorial, aprenderá más sobre-

• Cómo realizar la prueba TDD
• TDD vs. Pruebas tradicionales
• ¿Qué es la aceptación TDD y Developer TDD?
• Escalar TDD mediante el desarrollo basado en modelos ágiles (AMDD)
• Desarrollo basado en pruebas (TDD) vs. Desarrollo basado en modelos ágiles (AMDD)
• Ejemplo de TDD
• Beneficios de TDD

Cómo realizar la prueba TDD

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

1. Agregue una prueba.
2. Ejecute todas las pruebas y vea si falla alguna nueva.
3. Escriba algunas código.
4. Ejecute pruebas y refactorice el código.
5. Repita.

El ciclo TDD define

1. Escribe una prueba
2. Haz que se ejecute.
3. Cambia el código para hacerlo bien, es decir, Refactor.
4. Repita el proceso.

Algunas aclaraciones sobre TDD:

• TDD no se trata de «Pruebas» ni sobre «Diseño».
• TDD no significa «escribir algunas de las pruebas, luego construir un sistema que pase las pruebas.
• TDD no significa» hacer muchas pruebas. «

TDD vs. Pruebas tradicionales

El enfoque TDD es principalmente una técnica de especificación. Asegura que su código fuente sea probado a fondo en la confirmación nivel.

• Con las pruebas tradicionales, una prueba exitosa encuentra uno o más defectos. Es lo mismo que TDD. Cuando una prueba falla, ha progresado porque sabe que necesita resolver el problema.
• TDD asegura que su sistema realmente cumpla con los requisitos definidos para ella. Le ayuda a desarrollar su confianza en su sistema.
• En TDD, se centra más en el código de producción que verifica si las pruebas funcionarán correctamente. En las pruebas tradicionales, se centra más en el diseño de casos de prueba. Si la prueba mostrará la ejecución adecuada / incorrecta de la aplicación para cumplir con los requisitos.
• En TDD, usted logra una prueba de cobertura del 100%. Cada línea de código se prueba, a diferencia de las pruebas tradicionales.
• La combinación de las pruebas tradicionales y TDD conduce a la importancia de probar el sistema en lugar de la perfección del sistema.
• En Modelado ágil (AM), debe «probar con un propósito». Debe saber por qué está probando algo y qué nivel debe probarse.

¿Qué es TDD de aceptación y TDD de desarrollador?

Hay dos niveles de TDD

1. Aceptación TDD (ATDD): Con ATDD se escribe una única prueba de aceptación. Esta prueba cumple el requisito de la especificación o satisface el comportamiento del sistema. Después de eso, escriba solo el código de producción / funcionalidad suficiente para cumplir con esa prueba de aceptación. La prueba de aceptación se centra en el comportamiento general del sistema. ATDD también se conocía como desarrollo impulsado por el comportamiento (BDD).
2. Developer TDD: Con Developer TDD, escribe una prueba de desarrollador única, es decir, una prueba unitaria y luego solo el código de producción suficiente para cumplir con esa prueba. La prueba unitaria se centra en cada pequeña funcionalidad del sistema. El desarrollador TDD simplemente se llama TDD.

   El objetivo principal de ATDD y TDD es especificar requisitos detallados y ejecutables para su solución justo a tiempo (JIT). JIT significa tomar solo aquellos requisitos en consideración que son necesarios en el sistema. Así que aumente la eficiencia.

Escalado de TDD mediante el desarrollo basado en modelos ágiles (AMDD)

TDD es muy bueno en la especificación y validación detalladas. No puede 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 escalabilidad ágil que TDD no aborda.

Por lo tanto, AMDD se utiliza para problemas más importantes.

El ciclo de vida de AMDD.

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

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

Envisioning es uno de los procesos TDD de predecir / imaginar 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 sistema. Se realizan requisitos de alto nivel y modelado de arquitectura para una visualización exitosa.

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 que define la estrategia general del proyecto.

1. Iteración 0: Visualización

Hay dos sub-activaciones principales.

1. Previsión de requisitos iniciales.

   Puede llevar varios días identificar los requisitos de alto nivel y el alcance del sistema. El enfoque principal es explorar el modelo de uso, el modelo de dominio inicial y el modelo de interfaz de usuario (UI).

2. Visualización arquitectónica inicial.

   También se necesitan varios días para identificar la arquitectura del sistema. Permite establecer orientaciones técnicas para el proyecto. El enfoque principal es explorar diagramas de tecnología, flujo de interfaz de usuario (UI), modelos de dominio y casos de cambio.

1. Modelado de iteraciones:

   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.
• Primero con mayor prioridad se tendrá en cuenta el trabajo. Los elementos de trabajo agregados pueden volver a priorizarse o eliminarse de la pila de elementos en cualquier momento.
• El equipo analiza cómo van a implementar cada requisito. El modelado se usa para este propósito.
• El análisis y diseño del modelado se realiza para cada requisito que se implementará para esa iteración.

1. Modelo de asalto:

   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 preguntará a otro modelar con ellos. Esta sesión de modelado tomará aproximadamente de 5 a 10 minutos. Donde los miembros del equipo se reúnen para compartir la pizarra / papel.
• Ellos exploran los problemas hasta que no encuentran la causa principal del problema. Justo a tiempo, si un miembro del equipo identifica el problema que desea para resolverlo, necesitará la ayuda rápida de otros miembros del equipo.
• Luego, otros miembros del grupo exploran el problema y luego todos continúan como antes. También se denomina como modelado de pie o sesiones de control de calidad del cliente .

1. Test Driven Development (TDD).

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

1. Revisiones.

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

Test Driven Development (TDD) vs. Desarrollo basado en modelos ágiles (AMDD)

Ejemplo de TDD

Aquí, en este ejemplo, definiremos una contraseña de 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, escribimos el código que cumpla con todos los requisitos anteriores.

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

Ejecutaremos la clase anterior TestPassword ();

La salida se APRUEBA como se muestra a continuación;

Resultado:

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

Eliminaremos la clase PasswordValidator pv = new PasswordValidator () del código. Podemos llamar al método isValid () directamente por PasswordValidator. IsValid («Abc123»).(Vea la imagen a continuación)

Así que refactorizamos (cambiamos el código) como se muestra a continuación:

Escenario 3: Después de refactorizar, la salida muestra un estado fallido (ver imagen a continuación) esto se debe a que hemos eliminado la instancia. Por tanto, no hay ninguna referencia al método no estático isValid ().

Entonces necesitamos cambiar este método agregando la palabra «estática» antes de Boolean como public static boolean isValid (contraseña de cadena). Refactoring Class PasswordValidator () para eliminar el error anterior y pasar la prueba.

Salida:

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

Ventajas de TDD

• Error inicial notificación.

  Los desarrolladores prueban su código, pero en el mundo de las bases de datos, esto a menudo consiste en pruebas manuales o scripts únicos. Con TDD, crea, con el tiempo, 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 usará 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 fácil de entender.
  • TDD también obliga a escribir solo código de producción para pasar las pruebas según los requisitos del usuario.
• Confianza para refactorizar
  • Si refactoriza el código, puede haber posibilidades de rupturas en el código. Por lo tanto, al tener un conjunto de pruebas automatizadas, puede corregir esas interrupciones 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 pueden actualizar con riesgos mínimos.
• Bueno para el trabajo en equipo

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

• Bueno para 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 un código más limpio y menos complicado.

Resumen:

• TDD significa desarrollo impulsado por pruebas. Es un proceso de modificación del código con el fin de pasar una prueba diseñada previamente.
• Tiene más énfasis en el código de producción que en el diseño de casos de prueba.
• El desarrollo impulsado por pruebas es un proceso de modificar el código para pasar una prueba diseñada previamente.
• En Ingeniería de Software, a veces se lo conoce como «Prueba Primero Desarrollo».
• TDD incluye la refactorización de un código, es decir, cambiar / agregar alguna cantidad de código al código existente sin afectar el comportamiento del código.
• TDD cuando se usa, el código se vuelve más claro y simple de entender.

Este artículo es una contribución de Kanchan Kulkarni