Desarrollo basado en pruebas
Test Driven Development (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, los casos de prueba para cada funcionalidad se crean y prueban primero y si la prueba falla, se escribe el nuevo código para pasar la prueba y hacer que el código sea simple y sin errores.
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 un desarrollo impulsado por pruebas.
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 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?
- Escalado de TDD a través del desarrollo basado en modelos ágiles (AMDD)
- Desarrollo impulsado por 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,
- Agrega una prueba.
- Ejecute todas las pruebas y vea si falla alguna nueva.
- Escribe algún código.
- Ejecute pruebas y refactorice el código.
- Repetir.
El ciclo TDD define
- Escribe una prueba
- Hazlo correr.
- Cambie el código para hacerlo bien, es decir, Refactor.
- Repita el proceso.
Algunas aclaraciones sobre TDD:
- 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
El enfoque TDD es principalmente una técnica de especificación. Garantiza que su código fuente se pruebe a fondo a nivel de confirmación.
- Con las pruebas tradicionales, una prueba exitosa encuentra uno o más defectos. Es lo mismo que TDD. Cuando falla una prueba, ha avanzado porque sabe que debe resolver el problema.
- TDD garantiza que su sistema realmente cumpla con los requisitos definidos para él. Le 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, la atención 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, 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 pruebas tradicionales y TDD conduce a la importancia de probar el sistema en lugar de perfeccionarlo.
- En Agile Modeling (AM), debe "probar con un propósito". Debe saber por qué está probando algo y qué nivel debe probarse.
¿Qué es la aceptación TDD y Developer TDD?
Hay dos niveles de TDD
- 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).
- 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 a través del desarrollo basado en modelos ágiles (AMDD)
TDD es muy bueno en especificaciones y validaciones 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 impulsado por 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.
Visualizar 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, lo que define la estrategia general del proyecto.
- Iteración 0: Visualización
Hay dos sub-activaciones principales.
- 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).
- Proyecció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.
- 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.
- Se tomará en consideración el primer trabajo de mayor prioridad. 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 utiliza para este propósito.
- El análisis y diseño del modelado se realiza para cada requisito que se va a implementar para esa iteración.
- 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 pedirá a otro que modele con ellos. Esta sesión de modelado tomará aproximadamente de 5 a 10 minutos. Donde los miembros del equipo se reúnen para compartir pizarra / papel.
- 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 resolver, solicitará 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 conoce como modelado stand-up o sesiones de control de calidad del cliente.
- Desarrollo basado en pruebas (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.
- 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 al proyecto.
Desarrollo impulsado por pruebas (TDD) vs. Desarrollo basado en modelos ágiles (AMDD)
| TDD | 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 cumple con todos los requisitos anteriores.
Escenario 1 : Para ejecutar la prueba, creamos la clase PasswordValidator ();
Ejecutaremos por encima de la clase TestPassword ();
La salida es APROBADA como se muestra a continuación;
Salida :
Escenario 2 : Aquí podemos ver que 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") . (Ver imagen a continuación)
Así que Refactorizamos (código de cambio) de la siguiente manera:
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 ().
Por lo tanto, debemos cambiar este método agregando una palabra "estática" antes de Boolean como public static boolean isValid (contraseña de cadena). Refactorización de la clase PasswordValidator () para eliminar el error anterior y pasar la prueba.
Producción:
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
- Notificación temprana de errores.
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 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 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 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 para pasar una prueba diseñada previamente.
- Se hace más hincapié 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 modificación del 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 cierta cantidad de código al código existente sin afectar el comportamiento del código.
- Cuando se usa TDD, el código se vuelve más claro y fácil de entender.
Este artículo es una contribución de Kanchan Kulkarni.