BDD - Desarrollo basado en pruebas

Cuando observe cualquier referencia sobre el desarrollo impulsado por el comportamiento, encontrará el uso de frases como “BDD se deriva de TDD”, “BDD y TDD”. Para saber cómo llegó a existir BDD, por qué se dice que se deriva de TDD y qué es BDD y TDD, debe tener conocimiento de TDD.

¿Por qué realizar pruebas?

Para empezar, entremos en los fundamentos de las pruebas. El propósito de las pruebas es garantizar que el sistema que se construye funcione como se esperaba. Considere el siguiente ejemplo.

Por lo tanto, por experiencia hemos aprendido que descubrir un defecto a medida que se introduce y repararlo de inmediato sería rentable. Por lo tanto, es necesario escribir casos de prueba en cada etapa de desarrollo y prueba. Esto es lo que nos han enseñado nuestras prácticas de prueba tradicionales, lo que a menudo se denomina Prueba temprana.

Este enfoque de prueba se denomina enfoque de Prueba-Última, ya que la prueba se realiza después de completar una etapa.

Desafíos con el enfoque Test-Last

El enfoque Test-Last se siguió durante bastante tiempo en los proyectos de desarrollo de software. Sin embargo, en realidad, con este enfoque, como las pruebas tienen que esperar hasta que se completa la etapa en particular, a menudo se pasan por alto debido a:

  • Los retrasos en la finalización de la etapa.

  • Horarios ajustados.

  • Concéntrese en la entrega a tiempo, saltándose las pruebas.

Además, en el enfoque Test-Last, las pruebas unitarias, que se supone que deben realizar los desarrolladores, a menudo se omiten. Las diversas razones encontradas se basan en la mentalidad de los desarrolladores:

  • Son desarrolladores y no probadores.

  • Las pruebas son responsabilidad de los probadores.

  • Son eficientes en la codificación y su código no tendría defectos.

Esto da como resultado:

  • Comprometer la calidad del producto entregado.

  • Tener la responsabilidad de la calidad solo en los probadores.

  • Costos elevados de reparación de defectos, post entrega.

  • Incapacidad para obtener la satisfacción del cliente, lo que también significaría la pérdida de negocios repetidos, lo que afectaría la credibilidad.

Estos factores exigieron un cambio de paradigma, para centrarse en las pruebas. El resultado fue el enfoque Test-First.

Enfoque de prueba primero

El enfoque Test-First reemplaza la forma de desarrollo de adentro hacia afuera (escribir código y luego probar) a afuera hacia adentro (escribir prueba y luego codificar).

Este enfoque está incorporado en las siguientes metodologías de desarrollo de software (que también son ágiles):

  • miXtreme Pla programaciónXP).

  • Test Dhendido Ddesarrollo (TDD).

En estas metodologías, el desarrollador diseña y escribe las pruebas unitarias para un módulo de código antes de escribir una sola línea del módulo de código. Luego, el desarrollador crea el módulo de código con el objetivo de pasar la prueba unitaria. Por lo tanto, estas metodologías utilizan pruebas unitarias para impulsar el desarrollo.

El punto fundamental a tener en cuenta es que el objetivo es el desarrollo basado en pruebas.

Ciclo de refactorización rojo-verde

El desarrollo basado en pruebas se utiliza para desarrollar el código guiado por pruebas unitarias.

Step 1 - Considere un módulo de código que se va a escribir.

Step 2 - Escribe una prueba

Step 3 - Ejecuta la prueba.

La prueba falla, ya que el código aún no está escrito. Por lo tanto, el paso 2 generalmente se denomina escribir una prueba para fallar.

Step 4 - Escribe el código mínimo posible para pasar la prueba.

Step 5- Ejecute todas las pruebas para asegurarse de que todas pasen. Las pruebas unitarias están automatizadas para facilitar este paso.

Step 6 - Refactor.

Step 7 - Repita del Paso 1 al Paso 6 para el siguiente módulo de código.

Cada ciclo debe ser muy corto y una hora típica debe contener muchos ciclos.

Esto también se conoce popularmente como el Red-Green-Refactor ciclo, donde -

  • Red - Redacción de una prueba que falla.

  • Green - Redacción de código para aprobar la prueba.

  • Refactor - Elimine la duplicación y mejore el código a los estándares aceptables.

Pasos del proceso TDD

Los pasos de un proceso TDD se ilustran a continuación.

Ventajas de TDD

Los beneficios o ventajas del desarrollo basado en pruebas son:

  • El desarrollador debe comprender primero cuál debería ser el resultado deseado y cómo probarlo antes de crear el código.

  • El código de un componente se termina solo cuando la prueba pasa y el código se refactoriza. Esto asegura las pruebas y la refactorización antes de que el desarrollador pase a la siguiente prueba.

  • Como el conjunto de pruebas unitarias se ejecuta después de cada refactorización, la retroalimentación de que cada componente sigue funcionando es constante.

  • Las pruebas unitarias actúan como documentación viva que siempre depende de los datos.

  • Si se encuentra un defecto, el desarrollador crea una prueba para revelar ese defecto y luego modifica el código para que pase la prueba y se solucione el defecto. Esto reduce el tiempo de depuración. Todas las demás pruebas también se ejecutan y, cuando pasan, se asegura de que la funcionalidad existente no se rompa

  • El desarrollador puede tomar decisiones de diseño y refactorizar en cualquier momento, y la ejecución de las pruebas garantiza que el sistema siga funcionando. Esto hace que el software se pueda mantener.

  • El desarrollador tiene la confianza para realizar cualquier cambio, ya que si el cambio afecta alguna funcionalidad existente, lo mismo se revela al ejecutar las pruebas y los defectos se pueden corregir de inmediato.

  • En cada ejecución de prueba sucesiva, también se verifican todas las correcciones de defectos anteriores y se reduce la repetición del mismo defecto.

  • Como la mayoría de las pruebas se realizan durante el desarrollo en sí, las pruebas antes de la entrega se acortan.

Desventajas de TDD

El punto de partida son las Historias de usuarios, que describen el comportamiento del sistema. Por lo tanto, los desarrolladores a menudo se enfrentan a las siguientes preguntas:

  • ¿Cuándo realizar la prueba?

  • ¿Qué probar?

  • ¿Cómo saber si se cumple una especificación?

  • ¿El código ofrece valor comercial?

Conceptos erróneos sobre TDD

Los siguientes conceptos erróneos existen en la industria y necesitan aclaraciones.

Idea equivocada Aclaración
TDD se trata de pruebas y automatización de pruebas. TDD es una metodología de desarrollo que utiliza el enfoque Test-First.
TDD no implica ningún diseño. TDD incluye análisis y diseño críticos basados ​​en los requisitos. El diseño emerge durante el desarrollo.
TDD es solo a nivel de Unidad. TDD se puede utilizar en los niveles de integración y sistema.
TDD no se puede utilizar en proyectos de prueba tradicionales. TDD se hizo popular con Extreme Programming y se está utilizando en otras metodologías ágiles. Sin embargo, también se puede utilizar en proyectos de prueba tradicionales.
TDD es una herramienta.

TDD es una metodología de desarrollo, y después de cada nueva prueba unitaria pasa, se agrega a Automation Test Suite ya que todas las pruebas deben ejecutarse cada vez que se agrega un nuevo código o se modifica el código existente y también después de cada refactorización.

Por lo tanto, las herramientas de automatización de pruebas que admiten TDD facilitan este proceso.
TDD significa entregar pruebas de aceptación a los desarrolladores. TDD no significa entregar pruebas de aceptación a los desarrolladores.

Aceptación TDD

El desarrollo impulsado por pruebas de aceptación (ATDD) define los criterios de aceptación y las pruebas de aceptación durante la creación de historias de usuario, al principio del desarrollo. ATDD se enfoca en la comunicación y el entendimiento común entre los clientes, desarrolladores y probadores.

Las prácticas clave en ATDD son las siguientes:

  • Discuta escenarios del mundo real para construir una comprensión compartida del dominio.

  • Utilice esos escenarios para llegar a los criterios de aceptación.

  • Automatizar las pruebas de aceptación.

  • Centra el desarrollo en esas pruebas.

  • Utilice las pruebas como una especificación en vivo para facilitar el cambio.

Los beneficios de usar ATDD son los siguientes:

  • Los requisitos son inequívocos y sin lagunas funcionales.

  • Otros entienden los casos especiales que prevén los desarrolladores.

  • Las pruebas de aceptación guían el desarrollo.

TDD Vs BDD

Según Dan North, los programadores normalmente enfrentan los siguientes problemas al realizar el desarrollo basado en pruebas:

  • Donde empezar

  • Qué probar y qué no probar

  • Cuánto probar de una vez

  • Cómo llamar a sus pruebas

  • Cómo entender por qué falla una prueba

La solución a todos estos problemas es el desarrollo impulsado por el comportamiento. Ha evolucionado a partir de las prácticas ágiles establecidas y está diseñado para hacerlas más accesibles y efectivas para los equipos, nuevos en la entrega de software ágil. Con el tiempo, BDD ha crecido para abarcar la imagen más amplia del análisis ágil y las pruebas de aceptación automatizadas.

El principal difference between TDD and BDD es eso -

  • TDD describe cómo funciona el software.

  • Por otro lado, BDD -

    • Describe cómo el usuario final usa el software.

    • Fomenta la colaboración y la comunicación.

    • Destaca ejemplos de comportamiento del Sistema.

    • Apunta a las especificaciones ejecutables derivadas de los ejemplos