¿Cómo usar las pruebas unitarias cuando se usa BDD?

13

Estoy tratando de entender BDD. He leído algunos artículos y, como he entendido, BDD es "el siguiente paso" de TDD. Lo digo porque me parece que ambos son muy similares, y como pude leer en este artículo , el BDD nació como una mejora de TDD. Genial, me gusta mucho la idea.

Hay un punto práctico que no entiendo, pensé: hay un archivo .feature en el que el BA escribirá todo el comportamiento esperado en el que tendría el sistema. Como licenciado, no tiene idea de cómo está construido el sistema, por lo que escribiremos algo como esto:

  

+ Escenario 1: la cuenta está en crédito +

     

Dado que la cuenta está en crédito

     

Y la tarjeta es válida

     

Y el dispensador contiene efectivo

     

Cuando el cliente solicita efectivo

     

Luego, asegúrese de que la cuenta esté cargada y de que se dispense el efectivo

     

Y asegúrese de que la tarjeta sea devuelta

Ok, esto es genial, pero hay muchas partes del sistema que colaborarán para que pueda suceder (piense en Cuenta obj, Dispenser obj, Cliente obj y así sucesivamente). Para mí esto parece una prueba de integración.

Me gustaría tener Pruebas Unitarias. ¿Cómo pruebo el código que verifica si el dispensador tiene dinero? ¿O que se dispensa el efectivo? ¿O que la cuenta se debita cuando sea necesario? ¿Cómo puedo mezclar las pruebas unitarias con las pruebas "BA Created"?

    
pregunta JSBach 26.02.2015 - 15:44

3 respuestas

22

El desarrollo guiado por el comportamiento y el desarrollo guiado por pruebas son complementarios, pero no se reemplazan entre sí.

La forma en que se "comporta" la aplicación se describe en las Pruebas de Aceptación, que según BDD serían las Características y Escenarios escritas en Pepino.

Los detalles esenciales de cómo funciona cada componente pequeño se describen en Pruebas unitarias. Los resultados de las pruebas unitarias apoyan los escenarios que escribes en pepino.

Imagina el proceso para construir un auto.

Primero, el equipo de producto presenta sus ideas y finalmente las reduce a escenarios de uso:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

Sé que este escenario suena un poco tonto, pero es un requisito muy alto, centrado en el producto y el usuario final. Simplemente abrir la puerta, girar la llave y arrancar el motor implica muchos componentes diferentes trabajando juntos. Esta única prueba no es suficiente para asegurarse de que el vehículo funciona correctamente. Debe probar el motor de arranque, la batería, el alternador, la llave, el interruptor de encendido, y la lista continúa, solo para entrar al auto y ponerlo en marcha. Cada uno de esos componentes necesita sus propias pruebas.

El escenario anterior es una prueba "Big Picture". Cada componente del vehículo necesita pruebas de "Imagen pequeña" para asegurarse de que funcionan correctamente dentro del conjunto.

El software de construcción y prueba es el mismo en muchos aspectos. Usted diseña de arriba hacia abajo, luego construye de abajo hacia arriba. ¿Por qué tener una puerta que se levanta si ni siquiera se puede arrancar el motor? ¿Por qué tener un motor de arranque si no tienes batería?

Su equipo de productos realizará las Pruebas de aceptación y las desarrollará en Pepino. Esto le da el "Big Picture". Ahora depende del equipo de ingeniería el diseño de los componentes adecuados y la forma en que interactúan, luego prueba cada uno por separado: estas son tus pruebas unitarias.

Una vez que pasen las pruebas unitarias, comience a implementar los escenarios de pepino. Una vez que pasan, ha entregado lo que el equipo de producto ha pedido.

    
respondido por el Greg Burghardt 26.02.2015 - 19:54
8
  

Estoy tratando de entender BDD. He leído algunos artículos y, como he entendido, BDD es "el siguiente paso" de TDD. Digo eso porque encuentro que ambos son muy similares, y como pude leer en este artículo, BDD nació como una mejora de TDD.

En realidad, no, BDD es no "el siguiente paso" de TDD. Es es TDD. O más precisamente, es una reformulación de TDD.

Los creadores de BDD notaron que el mayor obstáculo para comprender que TDD no se trata de pruebas, sino de especificación de comportamiento, fue que toda la terminología de TDD se trata de pruebas y no de especificación de comportamiento. Es como tratar de no pensar en un elefante rosa cuando alguien te dice "intenta no pensar en un elefante rosa", excepto con la complicación adicional de estar en una habitación llena de elefantes rosados y un tipo que grita constantemente "elefante rosa, rosa". elefante, elefante rosa "en tu oreja.

Por lo tanto, reformularon TDD en términos de especificación de comportamiento. "Pruebas" y "casos de prueba" ahora son "ejemplos", "unidades" son "comportamientos", "afirmaciones" son "expectativas", y así sucesivamente.

Sin embargo, la metodología sigue siendo la misma. Comienzas con una prueba de aceptación (me refiero a "característica"), acercar a una prueba unitaria (me refiero a "ejemplo"), alejar el zoom, etc.

  

Me gustaría tener Pruebas Unitarias. ¿Cómo pruebo el código que verifica si el dispensador tiene dinero? ¿O que se dispensa el efectivo? ¿O que la cuenta se debita cuando sea necesario?    ¿Cómo puedo mezclar las pruebas unitarias con las pruebas "BA Created"?

De la misma manera que lo haces en TDD. Puede escribir sus características y sus ejemplos en diferentes marcos (por ejemplo, Cucumber y RSpec) o incluso en diferentes idiomas (por ejemplo, escribir ejemplos para un proyecto de C en C, y funciones en FIT / Fitnesse), puede usar un único marco de características para ambos ( por ejemplo, escribiendo ejemplos y características en Cucumber) o puede usar un marco de ejemplos único para ambos (por ejemplo, escribiendo ambos en RSpec). Ni siquiera tiene que usar un marco en absoluto.

Un ejemplo de TDD-done-right (que es idéntico a BDD) que usa un solo marco es JUnit, que contiene una mezcla de pruebas unitarias (ejemplos) y pruebas funcionales / de integración (características), todo escrito en JUnit En sí.

Creo que Kent Beck llama a esto "zoom". Comience con un nivel alto, luego "amplíe" los detalles y luego vuelva a salir.

    
respondido por el Jörg W Mittag 27.02.2015 - 05:42
1

Descargo de responsabilidad: no soy un experto en BDD, pero trato de darte mi punto de vista sobre el artículo al que has vinculado.

TDD es una técnica de implementación: primero escribe una prueba, luego implementa el método, ejecuta la prueba, refactoriza y agrega pruebas adicionales para el mismo método o para un nuevo método. TDD en realidad no define ninguna regla sobre cómo elegir los nombres de clase o método, eso depende de usted. TDD tampoco te dice "cuando hayas terminado".

Por lo tanto, cada vez que escriba una prueba para un nuevo método, debe elegir un nombre de método, y ese es el punto en el que aparece la BDD. Al elegir los nombres de los métodos utilizando los términos comerciales del escenario anterior, y al elegirlos en Una forma de describir el comportamiento de su clase, está haciendo BDD. Cada vez que se pregunte "tengo que agregar más pruebas", puede ver los escenarios dados por su licenciatura y verificar si ha implementado todas las piezas necesarias por completo. De lo contrario, deberá agregar más pruebas.

El autor del artículo también sugiere usar un esquema de nombres más relacionado con el comportamiento al elegir los nombres de sus pruebas, por eso sugiere reemplazar JUnit por una herramienta que no se basa en un esquema de nombres donde cada caso de prueba tenga para comenzar con el nombre "prueba". Aunque no conozco a JBehave, creo que esa es la principal diferencia entre esa herramienta y Junit.

Además, los escenarios de BDD también serán un modelo para las pruebas de integración, que normalmente agregará después de , completó los nombres de los métodos mediante TDD y luego agregó una cantidad razonable de pruebas unitarias.

A mi entender, TDD es un instrumento que puedes usar como parte de BDD, y BDD te ayuda a escribir las pruebas correctas y darles mejores nombres.

    
respondido por el Doc Brown 26.02.2015 - 19:20

Lea otras preguntas en las etiquetas