Sí, eso creo. Mi experiencia con BDD proviene principalmente del uso de Cucumber and Gherkin para crear y mantener las llamadas especificaciones ejecutables. Si no está familiarizado con el último término, una especificación ejecutable es una especificación que se puede ejecutar como una prueba automatizada. (Además: Gherkin es un lenguaje para escribir especificaciones ejecutables y Cucumber es una herramienta para automatizarlas).
Para aquellos que son nuevos en el tema, así es como se ve una especificación de estilo BDD muy simple escrita en Gherkin:
Característica: envío gratis
- ¿Cuál es la forma más rápida para que un programador de software de Japón migre a Canadá?
- ¿Qué herramientas o habilidades de codificación necesitaría para construir un reproductor de música que muestre cada sonido en una pista separada?
- ¿Qué es el ciclo de vida del desarrollo de software?
- ¿Cuál es el mejor lenguaje de programación para usar al construir una red social, PHP o Ruby? ¿Por qué?
- ¿Cuál es la solución para complicados procesos de construcción en el desarrollo de software?
Esquema del escenario: los pedidos superiores a $ 100 deben enviarse de forma gratuita
Artículos dados que valen en el carrito de John
Cuando John procede a pagar
Entonces se le debe ofrecer
Ejemplos:
El | compra | envío |
El | $ 99 | $ 5 de envío |
El | $ 100 | envío gratis |
El concepto de ejecución de especificaciones puede tener profundas implicaciones para sus proyectos. En esta respuesta, me gustaría hablar sobre una posible mejora: rastrear y finalmente eliminar los bumeranes.
Los bumeranes son funcionalidades que se rompen de vez en cuando, a pesar de los mejores esfuerzos de su equipo para arreglar el código roto para siempre. Los bumeranes obviamente afectan los presupuestos, los plazos y la moral negativamente porque el equipo tiene que perder el tiempo volviendo a la misma funcionalidad varias veces, mientras que las otras características tienen que esperar en la cola. Los bumeranes también son importantes para identificar y contener porque resaltan claramente las áreas en las que carece de conocimiento de dominio y donde aparecen problemas de comunicación. No es tan fácil prevenir los boomerangs como identificarlos, pero las especificaciones ejecutables pueden ayudarlo a disminuir el riesgo de que aparezca un boomerang.
Los bumeranes pueden aparecer cuando
- una funcionalidad trata con reglas de dominio complejas que son difíciles de entender para los extraños de la industria
- el equipo no identificó a una parte interesada importante que tuviera voz en el proceso de toma de decisiones
- el equipo no logró satisfacer a una parte interesada, subestimando sus solicitudes
- el equipo permitió el cuello de botella de un empleado y no documentó ni transfirió el conocimiento sobre las dificultades de una funcionalidad a otros miembros del equipo en caso de que ocurriera una rotación
- los clientes aún no están satisfechos con la solución a pesar de que se implementó exactamente como fue diseñada
Las especificaciones ejecutables con ejemplos pueden ayudarlo a reducir la probabilidad de la mayoría de las razones enumeradas anteriormente.
¿Cómo sucede eso? Cada especificación ejecutable es también una prueba de aceptación automatizada. Ahora, si está familiarizado con el concepto de prueba de regresión, ya puede sospechar hacia dónde se dirige mi razonamiento. En la mayoría de las situaciones de desarrollo de software, se considera una buena práctica de codificación, cuando se localiza y corrige un error, registrar una prueba que exponga el error y volver a ejecutar esa prueba regularmente después de los cambios posteriores en el programa. La prueba que verifica estos cambios se convierte en una prueba de regresión . Entonces, si agregamos pruebas de regresión a nuestras especificaciones ejecutables existentes cada vez que descubramos un mal funcionamiento, disminuiremos la probabilidad de reaparición de bumeranes. Y debido a que las especificaciones ejecutables se ocupan de características de alto nivel que son importantes para el negocio, ¡podemos estar seguros de que nuestras pruebas de regresión también serán importantes para el negocio!
Ahora, un ejemplo muy simple de una prueba de regresión en una especificación ejecutable sería algo como esto: volvamos a la especificación de envío en la parte superior de mi respuesta. Entiendo que lo que voy a escribir será un poco simplista, pero por favor tengan paciencia conmigo y verán lo que tengo en mente. Digamos que descubrimos que debido a un error banal en el envío gratuito de código solo se aplica a compras de $ 100. Entonces, si compra algo por $ 101, el error no le permitió obtener su envío gratis. Tan pronto como descubras eso, el equipo lo arregla. Pero pueden agregar una prueba de regresión a su especificación ejecutable:
Ejemplos:
El | compra | envío |
El | $ 99 | $ 5 de envío |
El | $ 100 | envío gratis |
El | $ 101 | envío gratis |
Debido a que la especificación es ejecutable, cada uno de los tres ejemplos anteriores tendrá que ser automatizado como prueba por desarrolladores y evaluadores. Pero ahora todo el equipo puede estar seguro de que el conjunto de pruebas automatizadas verificará si este error específico no reaparece cada vez que queramos implementar nuestros cambios en una instancia de producción.
A veces, los bumeranes pueden regresar varias veces. Cuanto más regresan, más importancia se merecen: más pruebas, más ejemplos. Se convierten en documentación. Ser una fuente única de verdad significa que cuando las partes interesadas se preparan para implementar una nueva historia de usuario o reparar una corrección de errores, pueden usar la suite para leer escenarios relevantes y verificar ejemplos importantes. Confiando en el conocimiento escrito a largo plazo en lugar de la memoria humana falible, pueden detectar inconsistencias y áreas problemáticas mucho más fácilmente y antes. Es por eso que los bumeranes, en caso de que aparezcan, definitivamente merecen tener un lugar destacado en sus especificaciones de pepino. Y volveremos al tema de los bumeranes que pertenecen al sistema de documentación viva en el capítulo 7, que hablará sobre la documentación.
Si desea leer más sobre el análisis de boomerangs y escribir especificaciones ejecutables, escribí un libro sobre el tema. “Escribir excelentes especificaciones” explora el arte de analizar los requisitos y lo ayudará a hacer que las especificaciones ejecutables escritas en Gherkin sean una parte central de su proceso de desarrollo. Los ejemplos anteriores están tomados del capítulo 5, llamado Elección de ejemplos para esquemas de escenarios . El libro también contiene otras técnicas que, combinadas con el poder de las especificaciones ejecutables, pueden ayudar a los equipos de BDD a entregar un excelente software a tiempo y dentro del presupuesto.
Si está interesado en comprar “Escribir excelentes especificaciones”, puede ahorrar un 39% con el código de promoción 39nicieja2 🙂