Desarrollo impulsado por el comportamiento - Guía rápida

Behavior Driven Development (BDD) es un proceso de desarrollo de software que surgió originalmente de Test Driven Development (TDD).

Según Dan North, responsable de la evolución de BDD, "BDD está utilizando ejemplos en múltiples niveles para crear una comprensión compartida y la incertidumbre de la superficie para entregar software que importa".

BDD usa ejemplos para ilustrar el comportamiento del sistema que están escritos en un lenguaje legible y comprensible para todos los involucrados en el desarrollo. Estos ejemplos incluyen:

• Convertido en especificaciones ejecutables.

• Utilizado como pruebas de aceptación.

BDD: características clave

El desarrollo impulsado por el comportamiento se centra en:

• Proporcionar un proceso compartido y herramientas compartidas que promuevan la comunicación con los desarrolladores de software, analistas de negocios y partes interesadas para colaborar en el desarrollo de software, con el objetivo de entregar un producto con valor comercial.

• Qué debe hacer un sistema y no cómo debe implementarse.

• Proporcionando mejor legibilidad y visibilidad.

• Verificando no solo el funcionamiento del software sino también que cumple con las expectativas del cliente.

Origen de BDD

El costo de reparar un defecto se multiplica por varios si el defecto no se detecta en el momento adecuado y se repara cuando se detecta. Considere el siguiente ejemplo.

Esto muestra que, a menos que los requisitos se obtengan correctamente, sería costoso corregir los defectos resultantes de una mala comprensión de los requisitos en una etapa posterior. Además, es posible que el producto final no cumpla con las expectativas del cliente.

La necesidad del momento es un enfoque de desarrollo que:

• Se basa en los requisitos.

• Se centra en los requisitos durante todo el desarrollo.

• Asegura que se cumplan los requisitos.

Un enfoque de desarrollo que puede hacerse cargo de los requisitos mencionados anteriormente es BDD. Por lo tanto, desarrollo impulsado por el comportamiento -

• Deriva ejemplos de diferentes comportamientos esperados del sistema.

• Permite escribir los ejemplos en un idioma utilizando los términos del dominio empresarial para garantizar una fácil comprensión por parte de todos los involucrados en el desarrollo, incluidos los clientes.

• Consigue ratificar los ejemplos con el cliente de vez en cuando mediante conversaciones.

• Se centra en los requisitos del cliente (ejemplos) durante todo el desarrollo.

• Utiliza ejemplos como pruebas de aceptación.

Prácticas BDD

Las dos prácticas principales de BDD son:

• Especificación por ejemplo (SbE)

• Desarrollo basado en pruebas (TDD)

Especificación por ejemplo

Specification by Example (SbE) utiliza ejemplos en conversaciones para ilustrar las reglas de negocio y el comportamiento del software que se va a construir.

La especificación por ejemplo permite a los propietarios de productos, analistas comerciales, evaluadores y desarrolladores eliminar los malentendidos comunes sobre los requisitos comerciales.

Desarrollo basado en pruebas

Test Driven Development, en el contexto de BDD, convierte los ejemplos en especificaciones ejecutables y legibles por humanos.

Los desarrolladores utilizan estas especificaciones como guía para implementar incrementos de nuevas funciones. Esto da como resultado una base de código ajustada y un conjunto de pruebas de regresión automatizadas que mantienen bajos los costos de mantenimiento durante toda la vida útil del software.

BDD ágil

En el desarrollo de software ágil, el método BDD se utiliza para llegar a un entendimiento común sobre las especificaciones pendientes.

Los siguientes pasos se ejecutan en Agile BDD:

• Los desarrolladores y el propietario del producto escriben en colaboración las especificaciones pendientes en un editor de texto sin formato.

• El propietario del producto especifica los comportamientos que esperan del sistema.

• Los desarrolladores

  • Complete las especificaciones con estos detalles de comportamiento.

  • Haga preguntas basadas en su comprensión del sistema.

• Se consideran los comportamientos actuales del sistema para ver si la nueva función romperá alguna de las funciones existentes.

Manifiesto ágil y BDD

El Manifiesto Ágil establece lo siguiente:

Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar:

• Individuals and interactions - sobre procesos y herramientas

• Working software - sobre documentación completa

• Customer collaboration - sobre negociación de contrato

• Responding to change - sobre Seguir un plan

Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

BDD se alinea con el manifiesto Agile de la siguiente manera:

Manifiesto ágil	Alineación BDD
Individuos e interacciones sobre procesos y herramientas.	BDD se trata de tener conversaciones.
Software de trabajo sobre documentación completa.	BDD se enfoca en facilitar la creación de software que tenga valor comercial.
Colaboración con el cliente sobre negociación de contratos.	BDD se enfoca en escenarios basados ​​en ideas con comunicación continua con el cliente a medida que avanza el desarrollo. No se basa en promesas.
Responde al cambio sobre el siguiente plan.	BDD se centra en la comunicación y la colaboración continuas que facilitan la absorción de cambios.

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, dado que 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 se incorpora a 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 dirigido por 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 conoce como 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 de 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 solucionar 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 está 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 centra en la comunicación y el entendimiento común entre los clientes, desarrolladores y evaluadores.

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 de análisis ágil y 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

En TDD, el término "Pruebas de aceptación" es engañoso. Las pruebas de aceptación en realidad representan el comportamiento esperado del sistema. En las prácticas ágiles, se enfatiza la colaboración de todo el equipo y las interacciones con el cliente y otras partes interesadas. Esto ha dado lugar a la necesidad de utilizar términos que sean fácilmente comprensibles para todos los involucrados en el proyecto.

TDD te hace pensar en lo necesario Behavior y por lo tanto el término 'Comportamiento' es más útil que el término ‘Test’. BDD es un desarrollo basado en pruebas con un vocabulario que se centra en el comportamiento y no en las pruebas.

En palabras de Dan North, "encontré el cambio de pensar en las pruebas a pensar en el comportamiento tan profundo que comencé a referirme a TDD como BDD, o desarrollo impulsado por el comportamiento". TDD se enfoca en cómo funcionará algo, BDD se enfoca en por qué lo construimos.

BDD responde a las siguientes preguntas a las que a menudo se enfrentan los desarrolladores:

Pregunta	Responder
¿Donde empezar?	de fuera hacia dentro
¿Qué probar?	Historias del usuario
¿Qué no probar?	Algo más

Estas respuestas dan como resultado el marco de la historia de la siguiente manera:

Story Framework

Como un [Role]

quiero [Feature]

así que eso [Benefit]

Esto significa, 'Cuando un Feature se ejecuta, el resultado Benefit es para la persona que juega el Role.'

BDD responde además a las siguientes preguntas:

Pregunta	Responder
¿Cuánto probar de una vez?	muy poco enfocado
¿Cómo llamar a sus pruebas?	plantilla de oración
Cómo entender por qué falla una prueba	documentación

Estas respuestas dan como resultado el marco de ejemplo de la siguiente manera:

Example Framework

Given algún contexto inicial,

When ocurre un evento,

Then asegurar algunos resultados.

Esto significa, 'Comenzando con el contexto inicial, cuando ocurre un evento en particular, sabemos cuáles son los resultados should be.

Así, el ejemplo muestra el comportamiento esperado del sistema. Los ejemplos se utilizan para ilustrar diferentes escenarios del sistema.

Historia y escenarios

Consideremos la siguiente ilustración de Dan North sobre un sistema de cajeros automáticos.

Historia

As a cliente,

I want retirar efectivo de un cajero automático,

so that No tengo que hacer cola en el banco.

Escenarios

Hay dos escenarios posibles para esta historia.

Scenario 1 - La cuenta está en crédito

Given la cuenta está en crédito

And la tarjeta es válida

And el dispensador contiene efectivo

When el cliente solicita efectivo

Then asegúrese de que la cuenta esté cargada

And asegúrese de que se dispensa efectivo

And asegúrese de que la tarjeta sea devuelta

Scenario 2 - La cuenta está sobregirada más allá del límite de sobregiro

Given la cuenta está sobregirada

And la tarjeta es válida

When el cliente solicita efectivo

Then asegúrese de que se muestre un mensaje de rechazo

And asegúrese de que no se dispensa efectivo

And asegúrese de que la tarjeta sea devuelta

El evento es el mismo en ambos escenarios, pero el contexto es diferente. Por tanto, los resultados son diferentes.

Ciclo de desarrollo

El ciclo de desarrollo de BDD es un outside-in Acercarse.

Step 1- Escriba un ejemplo de valor comercial de alto nivel (externo) (utilizando Pepino o RSpec / Carpincho) que se ponga rojo. (RSpec produce un marco BDD en el lenguaje Ruby)

Step 2 - Escriba un ejemplo de RSpec de nivel inferior (interior) para el primer paso de implementación que se pone rojo.

Step 3 - Implementar el código mínimo para pasar ese ejemplo de nivel inferior, ver cómo se vuelve verde.

Step 4 - Escriba el siguiente ejemplo de RSpec de nivel inferior presionando para pasar el Paso 1 que se pone rojo.

Step 5 - Repita los pasos del Paso 3 y el Paso 4 hasta que el ejemplo de alto nivel del Paso 1 se vuelva verde.

Note - Deben tenerse en cuenta los siguientes puntos:

• Red/green estado es un estado de permiso.

• Cuando sus pruebas de bajo nivel son verdes, tiene permiso para escribir nuevos ejemplos o refactorizar la implementación existente. No debe, en el contexto de la refactorización, agregar nueva funcionalidad / flexibilidad.

• Cuando sus pruebas de bajo nivel están en rojo, tiene permiso para escribir o cambiar el código de implementación solo para que las pruebas existentes se vuelvan verdes. Debe resistir la tentación de escribir el código para pasar su próxima prueba, que no existe, o implementar características que pueda pensar que son buenas (el cliente no lo habría pedido).

Según Gojko Adzic, autor de 'Specification by Example', Specification by Example es un conjunto de patrones de proceso que facilitan el cambio en los productos de software para garantizar que el producto correcto se entregue de manera eficiente ".

La especificación por ejemplo es un enfoque colaborativo para definir los requisitos y las pruebas funcionales orientadas al negocio para productos de software basados ​​en capturar e ilustrar los requisitos utilizando ejemplos realistas en lugar de declaraciones abstractas.

Especificación por ejemplo: descripción general

El objetivo de Especificación por ejemplo es centrarse en el desarrollo y la entrega de requisitos comerciales priorizados y verificables. Si bien el concepto de Especificación por ejemplo en sí mismo es relativamente nuevo, es simplemente una reformulación de las prácticas existentes.

Admite un vocabulario muy específico y conciso conocido como lenguaje ubicuo que:

• Habilita los requisitos ejecutables.

• Es utilizado por todos en el equipo.

• Es creado por un equipo multifuncional.

• Captura la comprensión de todos.

La especificación por ejemplo se puede utilizar como entrada directa en la creación de pruebas automatizadas que reflejen el dominio empresarial. Por lo tanto, el enfoque de Especificación por ejemplo es construir el producto correcto y construir el producto correctamente.

Propósito de la especificación por ejemplo

El objetivo principal de Specification by Example es construir el producto correcto. Se centra en la comprensión compartida, estableciendo así una única fuente de verdad. Permite la automatización de los criterios de aceptación para que el enfoque esté en la prevención de defectos en lugar de la detección de defectos. También promueve la prueba temprana para encontrar los defectos temprano.

Uso de SbE

La especificación por ejemplo se utiliza para ilustrar el comportamiento esperado del sistema que describe el valor comercial. La ilustración es por medio de ejemplos concretos y de la vida real. Estos ejemplos se utilizan para crear requisitos ejecutables que son:

• Comprobable sin traducción.

• Capturado en documentación en vivo.

Las siguientes son las razones por las que usamos ejemplos para describir especificaciones particulares:

• Son más fáciles de entender.

• Son más difíciles de malinterpretar.

Ventajas de SbE

Las ventajas de usar Especificación por ejemplo son:

• Mayor calidad

• Reducción de residuos

• Riesgo reducido de defectos de producción

• Esfuerzo concentrado

• Los cambios se pueden realizar de forma más segura

• Mayor participación empresarial

Aplicaciones de SbE

Especificación por ejemplo buscar aplicaciones en -

• Ya sea una empresa compleja o una organización compleja.

• No funciona bien para problemas puramente técnicos.

• No funciona bien para productos de software centrados en la interfaz de usuario.

• También se puede aplicar a sistemas heredados.

Pruebas de aceptación y SbE

Las ventajas de la especificación por ejemplo en términos de pruebas de aceptación son:

• Se utiliza una única ilustración tanto para los requisitos detallados como para las pruebas

• El avance del proyecto está en términos de pruebas de aceptación -

  • Cada prueba es para probar un comportamiento.

  • Una prueba está pasando por un comportamiento o no lo es.

  • Una prueba aprobatoria representa que se completa el comportamiento particular.

  • Si un proyecto que requiere que se completen 100 comportamientos tiene 60 comportamientos completados, entonces está terminado en un 60%.

• Los probadores pasan de la reparación de defectos a la prevención de defectos y contribuyen al diseño de la solución.

• La automatización permite una comprensión instantánea del impacto de un cambio de requisitos en la solución.

Especificación por ejemplo: lo que significa para diferentes roles

El objetivo de Especificación por ejemplo es promover la colaboración de todos los miembros del equipo, incluido el cliente durante todo el proyecto para ofrecer valor comercial. Todos, para una mejor comprensión, utilizan el mismo vocabulario.

Papel	Uso de SbE
Analista de negocios	Los requisitos son inequívocos y sin lagunas funcionales. Desarrolladores, lean las especificaciones.
Desarrollador	Los desarrolladores comprenden mejor lo que se está desarrollando. El progreso del desarrollo se rastrea mejor contando las especificaciones que se han desarrollado correctamente.
Ensayador	Los probadores comprenden mejor lo que se está probando. Los probadores participan desde el principio y tienen un papel en el diseño. Los probadores trabajan para la prevención de defectos en lugar de la detección de defectos.
Todos	Se ahorra tiempo identificando errores desde el principio. Se produce un producto de calidad desde el principio.

SbE: un conjunto de patrones de proceso

Como hemos visto al comienzo de este capítulo, la especificación por ejemplo se define como un conjunto de patrones de proceso que facilitan el cambio en los productos de software para garantizar que el producto correcto se entregue de manera eficiente.

Los patrones de proceso son:

• Especificación colaborativa

• Ilustrando especificaciones usando ejemplos

• Refinando la especificación

• Ejemplos de automatización

• Validando frecuentemente

• Documentación viva

Especificación colaborativa

Los objetivos de la especificación colaborativa son:

• Obtenga los distintos roles en un equipo para tener un entendimiento común y un vocabulario compartido.

• Haga que todos se involucren en el proyecto para que puedan contribuir con sus diferentes perspectivas sobre una característica.

• Garantice la comunicación compartida y la propiedad de las funciones.

Estos objetivos se cumplen en un taller de especificación también conocido como la reunión de los Tres Amigos. Los Tres Amigos son BA, QA y el desarrollador. Aunque hay otros roles en el proyecto, estos tres serían responsables desde la definición hasta la entrega de las características.

During the meeting −

• El analista de negocios (BA) presenta los requisitos y pruebas para una nueva característica.

• Los tres Amigos (BA, Desarrollador y QA) discuten la nueva característica y revisan las especificaciones.

• El QA y el desarrollador también identifican los requisitos que faltan.

• Los tres amigos

  • Utilice un modelo compartido con un lenguaje ubicuo.

  • Utilice vocabulario de dominio (se mantiene un glosario si es necesario).

  • Busque diferencias y conflictos.

• No salte a los detalles de implementación en este momento.

• Llegue a un consenso sobre si una característica se especificó suficientemente.

• Un sentido compartido de los requisitos y la propiedad de la prueba facilita las especificaciones de calidad

• Los requisitos se presentan como escenarios, que proporcionan requisitos explícitos e inequívocos. Un escenario es un ejemplo del comportamiento del sistema desde la perspectiva de los usuarios.

Ilustrando la especificación usando ejemplos

Los escenarios se especifican utilizando la estructura Given-When-Then para crear una especificación comprobable:

Given <alguna condición previa>

And <condiciones previas adicionales> Optional

When <ocurre una acción / desencadenante>

Then <alguna condición de publicación>

And <condiciones de publicación adicionales> Optional

Esta especificación es un ejemplo de comportamiento del sistema. También representa un criterio de aceptación del sistema.

El equipo analiza los ejemplos y la retroalimentación se incorpora hasta que hay un acuerdo de que los ejemplos cubren el comportamiento esperado de la función. Esto asegura una buena cobertura de prueba.

Refinando la especificación

Para refinar una especificación,

• Sea preciso al escribir los ejemplos. Si un ejemplo se vuelve complejo, divídalo en ejemplos más simples.

• Concéntrese en la perspectiva empresarial y evite los detalles técnicos.

• Considere las condiciones tanto positivas como negativas.

• Adhiérase al vocabulario específico del dominio.

• Analice los ejemplos con el cliente.

  • Elija conversaciones para lograr esto.

  • Considere solo aquellos ejemplos que le interesan al cliente. Esto permite la producción del código requerido únicamente y evita cubrir todas las combinaciones posibles, que pueden no ser necesarias.

• Para asegurarse de que el escenario pasa, todos los casos de prueba para ese escenario deben pasar. Por lo tanto, mejore las especificaciones para hacerlas comprobables. Los casos de prueba pueden incluir varios rangos y valores de datos (casos de límite y esquina), así como diferentes reglas comerciales que dan como resultado cambios en los datos.

• Especifique reglas comerciales adicionales, como cálculos complejos, manipulación / transformación de datos, etc.

• Incluya escenarios no funcionales (por ejemplo, rendimiento, carga, usabilidad, etc.) como Especificación por ejemplo

Ejemplos de automatización

La capa de automatización debe mantenerse muy simple, simplemente cableando la especificación al sistema bajo prueba. Puedes usar una herramienta para lo mismo.

Realice pruebas de automatización mediante el lenguaje específico del dominio (DSL) y muestre una conexión clara entre las entradas y las salidas. Céntrese en la especificación y no en el guión. Asegúrese de que las pruebas sean precisas, fáciles de entender y comprobables.

Validar con frecuencia

Incluya una validación de ejemplo en su canal de desarrollo con cada cambio (adición / modificación). Hay muchas técnicas y herramientas que pueden (y deben) adoptarse para ayudar a garantizar la calidad de un producto. Giran en torno a tres principios clave:Test Early, Test Well y Test Often.

Ejecute las pruebas con frecuencia para que pueda identificar los eslabones débiles. Los ejemplos que representan los comportamientos ayudan a rastrear el progreso y se dice que un comportamiento está completo solo después de que pasa la prueba correspondiente.

Documentación viva

Mantenga las especificaciones lo más simples y breves posible. Organice las especificaciones y evolucione a medida que avanza el trabajo. Haga que la documentación sea accesible para todos los miembros del equipo.

Especificación mediante pasos de proceso de ejemplo

La ilustración muestra los pasos del proceso en Especificación por ejemplo.

Anti-patrones

Los anti-patrones son ciertos patrones en el desarrollo de software que se consideran una mala práctica de programación. A diferencia de los patrones de diseño, que son enfoques comunes a problemas comunes, que se han formalizado y generalmente se consideran una buena práctica de desarrollo, los antipatrones son lo opuesto y no son deseables.

Los antipatrones dan lugar a varios problemas.

Anti-patrón	Problemas
Sin colaboración	Muchas suposiciones Construyendo algo incorrecto Probando algo incorrecto Sin darse cuenta cuando el código está terminado
Sin darse cuenta cuando el código está terminado	Pruebas difíciles de mantener Especificaciones difíciles de entender Pérdida de interés de los representantes comerciales
Ejemplos demasiado detallados o centrados en la interfaz de usuario	Pruebas difíciles de mantener Especificaciones difíciles de entender Pérdida de interés de los representantes comerciales
Subestimar el esfuerzo requerido	Los equipos piensan que han fallado y se decepcionan temprano

Solución a los problemas: calidad

La calidad se puede garantizar vigilando los antipatrones. Para minimizar los problemas creados por anti-patrones, debe:

• Reúnanse para especificar usando ejemplos.

• Limpiar y mejorar los ejemplos.

• Escribe un código que satisfaga los ejemplos.

• Automatice los ejemplos e impleméntelos.

• Repita el enfoque para cada historia de usuario.

Resolver los problemas debidos a anti-patrones significa adherirse a:

• Collaboration.

• Centrándonos en qué.

• Centrándose en los negocios.

• Estar preparado.

Entendamos lo que significa cada uno de los anteriores.

Colaboración

En colaboración -

• Los empresarios, los desarrolladores y los probadores aportan información desde sus propias perspectivas.

• Los ejemplos automatizados demuestran que el equipo ha construido lo correcto.

• El proceso es más valioso que las pruebas mismas.

Centrándonos en lo que

Debes concentrarte en la pregunta: 'qué'. Mientras se enfoca en 'qué' -

• No intente cubrir todos los casos posibles.

• No olvide utilizar diferentes tipos de pruebas.

• Mantenga los ejemplos lo más simples posible.

• Los ejemplos deben ser fácilmente comprensibles para los usuarios del sistema.

• Las herramientas no deben jugar un papel importante en los talleres.

Centrándose en los negocios

Para centrarse en el negocio:

• Mantenga la especificación según la intención comercial.

• Incluya empresas en la creación y revisión de especificaciones.

• Ocultar todos los detalles en la capa de automatización.

Estar preparado

Esté preparado para lo siguiente:

• Los beneficios no son evidentes de inmediato, incluso cuando se cambian las prácticas del equipo.

• Presentar SbE es un desafío.

• Requiere tiempo e inversiones.

• Las pruebas automatizadas no son gratuitas.

Herramientas

El uso de herramientas no es obligatorio para la Especificación por ejemplo, aunque en la práctica hay varias herramientas disponibles. Hay casos que tienen éxito siguiendo la Especificación por ejemplo incluso sin utilizar una herramienta.

Las siguientes herramientas admiten la especificación por ejemplo:

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog

Los equipos de desarrollo a menudo tienen la idea errónea de que BDD es un marco de herramientas. En realidad, BDD es un enfoque de desarrollo más que un marco de herramientas. Sin embargo, como en el caso de otros enfoques de desarrollo, también existen herramientas para BDD.

Varias herramientas BDD están en uso para diferentes plataformas y lenguajes de programación. Ellos son -

• Pepino (marco rubí)

• SpecFlow (marco .NET)

• Behave (marco de Python)

• JBehave (marco de Java)

• JBehave Web (marco Java con integración de Selenium)

• Lechuga (marco de Python)

• Concordion (marco de Java)

• Behat (marco PHP)

• Kahlan (marco PHP)

• DaSpec (marco de JavaScript)

• Jasmine (marco de JavaScript)

• Cucumber-js (marco de JavaScript)

• Squish GUI Tester (herramienta de prueba BDD GUI para JavaScript, Python, Perl, Ruby y Tcl)

• Spock (marco Groovy)

• Yadda (compatibilidad con el lenguaje Gherkin para marcos como Jasmine (marco JavaScript))

Pepino

Cucumber es una herramienta gratuita para especificaciones ejecutables que se utilizan a nivel mundial. Cucumber permite que los equipos de desarrollo de software describan cómo debe comportarse el software en texto plano. El texto está escrito en un lenguaje específico de dominio legible para empresas y sirve como documentación, pruebas automatizadas y ayuda para el desarrollo, todo en un solo formato. Puedes usar más de cuarenta idiomas hablados diferentes (inglés, chino, etc.) con Cucumber.

Pepino - Características principales

Las características clave de Pepino son las siguientes:

• El pepino se puede utilizar para especificaciones ejecutables, automatización de pruebas y documentación viva.

• Cucumber funciona con Ruby, Java, NET, Flex o aplicaciones web escritas en cualquier idioma.

• El pepino admite pruebas más concisas en tablas, similar a lo que hace FIT.

• Cucumber ha revolucionado el ciclo de vida del desarrollo de software al combinar requisitos, pruebas automatizadas y documentación en uno coherente: especificaciones ejecutables de texto sin formato que validan el software.

SpecFlow

SpecFlow es una herramienta BDD para la plataforma .NET. SpecFlow es un proyecto de código abierto. El código fuente está alojado en GitHub.

SpecFlow utiliza la sintaxis de Gherkin para las funciones. El formato Gherkin fue introducido por Cucumber y también lo utilizan otras herramientas. El lenguaje Gherkin se mantiene como un proyecto en GitHub -https://github.com/cucumber/gherkin

Comportarse

Behave se utiliza para el marco de Python.

• Behave funciona con tres tipos de archivos almacenados en un directorio llamado "características":

  • archivos de características con sus escenarios de comportamiento en él.

  • Directorio de "pasos" con implementaciones de pasos de Python para los escenarios.

  • Opcionalmente, algunos controles ambientales (código para ejecutar antes y después de los pasos, escenarios, funciones o todo el partido de disparo).

• Las características de Behave están escritas usando Gherkin (con algunas modificaciones) y se denominan "name.feature".

• Las etiquetas adjuntas a una característica y escenario están disponibles en las funciones del entorno a través del objeto "característica" o "escenario" que se les pasa. En esos objetos hay un atributo llamado "etiquetas" que es una lista de los nombres de las etiquetas adjuntas, en el orden en que se encuentran en el archivo de características.

• Modificaciones al estándar de pepinillo -

  • Behave puede analizar archivos Gherkin estándar y amplía Gherkin para permitir palabras clave de paso en minúsculas porque a veces pueden permitir especificaciones de características más legibles

Lechuga

La lechuga es una herramienta BDD muy simple basada en Pepino. Puede ejecutar descripciones funcionales de texto sin formato como pruebas automatizadas para proyectos de Python. La lechuga tiene como objetivo las tareas más habituales en BDD.

Concordion

Concordion es una herramienta de código abierto para automatizar la especificación por ejemplo para Java Framework.

Si bien las características principales son simples, la API de marco de extensión de gran alcance le permite agregar funcionalidad, como usar hojas de cálculo de Excel como especificaciones, agregar capturas de pantalla a la salida, mostrar información de registro, etc.

Concordion le permite escribir las especificaciones en lenguaje normal usando párrafos, tablas y la puntuación adecuada y el lenguaje estructurado usando Given / When / Then no es necesario.

Concordion se ha portado a otros idiomas, incluidos:

• C # (Concordion.NET)

• Python (PyConcordion)

• Ruby (Ruby-Concordion)

Cucumber es una herramienta que admite especificaciones ejecutables, automatización de pruebas y documentación viva.

El desarrollo impulsado por el comportamiento amplía la especificación mediante el ejemplo. También formaliza las mejores prácticas de desarrollo basado en pruebas, en particular, la perspectiva de trabajar desde afuera hacia adentro. El trabajo de desarrollo se basa en especificaciones ejecutables.

los key features de las especificaciones ejecutables son las siguientes:

• Las especificaciones ejecutables son:

  • Derivado de ejemplos, que representan los comportamientos del sistema.

  • Escrito con la colaboración de todos los involucrados en el desarrollo, incluidas las empresas y las partes interesadas.

  • Basado en criterio de aceptación.

• Las pruebas de aceptación que se basan en las especificaciones ejecutables están automatizadas.

• Se utiliza un lenguaje omnipresente compartido para escribir las especificaciones ejecutables y las pruebas automatizadas de manera que:

  • Se utiliza terminología específica de dominio durante todo el desarrollo.

  • Todos, incluidos los clientes y las partes interesadas, hablan sobre el sistema, sus requisitos y su implementación, de la misma manera.

  • Los mismos términos se utilizan para discutir el sistema presente en los requisitos, documentos de diseño, código, pruebas, etc.

  • Cualquiera puede leer y comprender un requisito y cómo generar más requisitos.

  • Los cambios pueden adaptarse fácilmente.

  • Se mantiene la documentación en vivo.

Cucumber ayuda con este proceso, ya que une las especificaciones ejecutables con el código real del sistema y las pruebas de aceptación automatizadas.

La forma en que lo hace está diseñada para que los clientes y los desarrolladores trabajen juntos. Cuando pasa una prueba de aceptación, significa que la especificación del comportamiento del sistema que representa se ha implementado correctamente.

Prueba de aceptación típica de pepino

Considere el siguiente ejemplo.

Feature − Sign up

• Registrarse debe ser rápido y amigable.

• Escenario: registro exitoso

  • New los usuarios deben recibir un correo electrónico de confirmación y ser recibidos personalmente.

  • Given He optado por registrarme.

  • When Me registro con datos válidos.

  • Then Debería recibir un correo electrónico de confirmación.

  • And Debería ver un mensaje de saludo personalizado.

En este ejemplo, podemos ver que:

• Las pruebas de aceptación se refieren a Features.

• Las funciones se explican por Scenarios.

• Los escenarios consisten en Steps.

La especificación está escrita en un lenguaje natural en un archivo de texto sin formato, pero es ejecutable.

Trabajo de pepino

Cucumber es una herramienta de línea de comandos que procesa archivos de texto que contienen las características en busca de escenarios que se puedan ejecutar en su sistema. Entendamos cómo funciona el pepino.

• Hace uso de un montón de convenciones sobre cómo se nombran los archivos y dónde están ubicados (las carpetas respectivas) para facilitar el inicio.

• Pepino le permite mantener especificaciones, pruebas automatizadas y documentación en el mismo lugar.

• Cada escenario es una lista de pasos que describen las condiciones previas, acciones y condiciones posteriores del escenario; Si cada paso se ejecuta sin ningún error, el escenario se marca como aprobado.

• Al final de una carrera, Cucumber informará cuántos escenarios pasaron.

• Si algo falla, proporciona información sobre lo que falló para que el desarrollador pueda progresar.

En Pepino, Features, Scenarios, y los pasos están escritos en un idioma llamado Gherkin.

Gherkin es un texto sin formato en inglés (o uno de más de 60 idiomas) con una estructura. Gherkin es fácil de aprender y su estructura te permite escribir ejemplos de manera concisa.

• Cucumber ejecuta sus archivos que contienen especificaciones ejecutables escritas en Gherkin.

• Pepino necesita definiciones de pasos para traducir los pasos de pepinillo en texto plano en acciones que interactúen con el sistema.

• Cuando Cucumber ejecuta un paso en un escenario, buscará una definición de paso coincidente para ejecutar.

• Una definición de paso es una pequeña pieza de código con un patrón adjunto.

• El patrón se utiliza para vincular la definición de paso a todos los pasos coincidentes, y el código es lo que Cucumber ejecutará cuando vea un paso Gherkin.

• Cada paso va acompañado de una definición de paso.

• La mayoría de los pasos recopilarán información y luego se delegarán en un marco que es específico para el dominio de su aplicación para realizar llamadas en su marco.

Cucumber admite más de una docena de plataformas de software diferentes. Puede elegir la implementación de pepino que más le convenga. Cada implementación de Cucumber proporciona la misma funcionalidad general y también tiene su propio procedimiento de instalación y funcionalidad específica de la plataforma.

Mapeo de pasos y definiciones de pasos

La clave de Pepino es el mapeo entre Pasos y Definiciones de Pasos.

Implementaciones de pepino

A continuación se muestran las implementaciones de Pepino.

	Ruby / JRuby
	JRuby (usando Cucumber-JVM)
	Java
	Groovy
	.NET (usando SpecFlow)
	JavaScript
	JavaScript (usando Cucumber-JVM y Rhino)
	Clojure
	Gosu
	Lua
	PHP (usando Behat)
	Jython
	C ++
	Tcl

Integración del marco

A continuación se muestran las implementaciones de Framework.

	Ruby on Rails
	Selenio
	PicoContainer
	Marco de primavera
	Watir

El pepinillo es un idioma que se usa para escribir Features, Scenarios, and Steps. El propósito de Gherkin es ayudarnos a redactar requisitos concretos.

Para comprender lo que queremos decir con requisitos concretos, considere el siguiente ejemplo:

Se debe evitar que los clientes ingresen detalles de tarjetas de crédito no válidas.

Versus

Si un cliente ingresa un número de tarjeta de crédito que no tiene exactamente 16 dígitos, cuando intenta enviar el formulario, debe volver a mostrarse con un mensaje de error que le advierte del número correcto de dígitos.

Este último no tiene ambigüedad y evita errores y es mucho más comprobable.

Gherkin está diseñado para crear requisitos más concretos. En Gherkin, el ejemplo anterior se ve así:

Feature

Comentarios al ingresar detalles de tarjetas de crédito no válidas Feature Definition

En las pruebas de usuario, hemos visto a muchas personas que cometen errores Documentación

Background True for all Scenarios Below

Given He elegido un artículo para comprar

And Estoy a punto de ingresar el número de mi tarjeta de crédito

Scenario - Número de tarjeta de crédito demasiado cortoScenario Definition

When Ingresé un número de tarjeta que tiene menos de 16 dígitos

And todos los demás detalles son correctos

And Presento el formularioSteps

Then el formulario debe volver a mostrarse

And Debería ver un mensaje informándome del número correcto de dígitos

Formato y sintaxis de pepinillo

Los archivos Gherkin son archivos de texto sin formato y tienen la extensión .feature. Cada línea que no esté en blanco debe comenzar con una palabra clave Gherkin, seguida de cualquier texto que desee. Las palabras clave son:

• Feature

• Scenario

• Dado, cuándo, entonces y, pero (pasos)

• Background

• Esquema del escenario

• Examples

• "" "(Cadenas de documentos)

• | (Tablas de datos)

• @ (Etiquetas)

• # (Comentarios)

• *

Característica

los FeatureLa palabra clave se utiliza para describir una función de software y para agrupar los escenarios relacionados. Una característica tiene tres elementos básicos:

• La palabra clave - Característica.

• El nombre de la función, proporcionado en la misma línea que la palabra clave de la función.

• Una descripción opcional (pero muy recomendable) que puede abarcar varias líneas, es decir, todo el texto entre la línea que contiene la palabra clave Característica y una línea que comienza con Escenario, Antecedentes o Esquema del escenario.

Además de un nombre y una descripción, las características contienen una lista de escenarios o esquemas de escenarios, y un fondo opcional.

Es convencional nombrar un .featurearchivo tomando el nombre de la función, convirtiéndolo a minúsculas y reemplazando los espacios con subrayados. Por ejemplo,

feedback_when_entering_invalid_credit_card_details.feature

Para identificar características en su sistema, puede utilizar lo que se conoce como una "plantilla de inyección de características".

Para <cumplir algún objetivo> como <tipo de usuario> quiero <a función>

Descripciones

Algunas partes de los documentos Gherkin no tienen que empezar con una palabra clave.

En las líneas que siguen a una Característica, escenario, esquema de escenario o ejemplos, puede escribir lo que quiera, siempre que ninguna línea comience con una palabra clave. Esta es la forma de incluir descripciones.

Guión

Para expresar el comportamiento de su sistema, adjunte uno o más escenarios con cada Característica. Es típico ver de 5 a 20 escenarios por función para especificar completamente todos los comportamientos relacionados con esa función.

Los escenarios siguen el siguiente patrón:

• Describe un contexto inicial

• Describe un evento

• Describe un resultado esperado

Comenzamos con un contexto, describimos una acción y verificamos el resultado. Esto se hace con pasos. Gherkin proporciona tres palabras clave para describir cada uno de los contextos, acciones y resultados como pasos.

• Given - Establecer contexto

• When - Realizar acción

• Then - Verificar resultado

Estas palabras clave proporcionan legibilidad del escenario.

Example

Scenario - Retirar dinero de la cuenta.

• Given Tengo $ 100 en mi cuenta.

• When Solicito $ 20.

• Then Se deben dispensar $ 20.

Si hay varios Given o When pasos uno debajo del otro, puede usar And o But. Le permiten especificar escenarios en detalle.

Example

Scenario - Intento de retiro con tarjeta robada.

• Given Tengo $ 100 en mi cuenta.

• But mi tarjeta no es válida.

• When Solicito $ 50.

• Then mi tarjeta no debe ser devuelta.

• And Deberían decirme que contacte con el banco.

Al crear escenarios, recuerde que 'cada escenario debe tener sentido y poder ejecutarse independientemente de cualquier otro escenario'. Esto significa

• No puede hacer que la condición de éxito de un escenario dependa del hecho de que se ejecutó otro escenario antes.

• Cada escenario crea su contexto particular, ejecuta una cosa y prueba el resultado.

Tales escenarios brindan los siguientes beneficios:

• Las pruebas serán más sencillas y fáciles de entender.

• Puede ejecutar solo un subconjunto de sus escenarios y no tiene que preocuparse por la rotura de su conjunto de prueba.

• Dependiendo de su sistema, es posible que pueda ejecutar las pruebas en paralelo, reduciendo la cantidad de tiempo necesario para ejecutar todas sus pruebas.

Esquema del escenario

Si tiene que escribir escenarios con varias entradas o salidas, puede terminar creando varios escenarios que solo se diferencian por sus valores. La solución es utilizar el esquema del escenario. Para escribir un esquema de escenario,

• Las variables en los pasos del esquema del escenario están marcadas con <y>.

• Los diversos valores de las variables se dan como ejemplos en una tabla.

Example

Suponga que está escribiendo una característica para sumar dos números en una calculadora.

Feature - Agregar.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

Una sección de esquema de escenario siempre va seguida de una o más secciones de ejemplos, que son un contenedor para una tabla. La tabla debe tener una fila de encabezado correspondiente a las variables en los pasos del esquema del escenario. Cada una de las filas siguientes creará un nuevo escenario, completando los valores de las variables

SpecFlow es un proyecto de código abierto. El código fuente está alojado en GitHub. Los archivos de características que utiliza SpecFlow para almacenar un criterio de aceptación para las características (casos de uso, historias de usuario) en su aplicación se definen utilizando la sintaxis de Gherkin.

El formato Gherkin fue introducido por Cucumber y también lo utilizan otras herramientas. El lenguaje Gherkin se mantiene como un proyecto en GitHub -https://github.com/cucumber/gherkin

Elementos de características y SpecFlow

Las características clave de los elementos Feature son:

• El elemento de característica proporciona un encabezado para el archivo de características. El elemento de característica incluye el nombre y una descripción de alto nivel de la característica correspondiente en su aplicación.

  • SpecFlow genera una clase de prueba unitaria para el elemento de la característica, con el nombre de la clase derivado del nombre de la característica.

  • SpecFlow genera pruebas unitarias ejecutables a partir de los escenarios que representan los criterios de aceptación.

• Un archivo de características puede contener múltiples escenarios que se utilizan para describir las pruebas de aceptación de la característica.

  • Los escenarios tienen un nombre y pueden constar de varios pasos de escenario.

  • SpecFlow genera un método de prueba unitaria para cada escenario, con el nombre del método derivado del nombre del escenario.

Pasos de escenarios múltiples

Los escenarios pueden tener varios pasos de escenario. Hay tres tipos de pasos que definen las condiciones previas, acciones o pasos de verificación que conforman la prueba de aceptación.

• Los diferentes tipos de pasos comienzan con el Given, When o Then palabras clave respectivamente y los pasos posteriores del mismo tipo se pueden vincular utilizando el And y But palabras clave.

• La sintaxis de Gherkin permite cualquier combinación de estos tres tipos de pasos, pero un escenario suele tener distintos bloques de Given, When y Then declaraciones.

• Los pasos del escenario se definen mediante texto y pueden tener una tabla adicional denominada DataTable o texto de varias líneas denominado argumentos DocString.

• Los pasos del escenario son una forma principal de ejecutar cualquier código personalizado para automatizar la aplicación.

• SpecFlow genera una llamada dentro del método de prueba unitaria para cada paso del escenario. La llamada es realizada por el tiempo de ejecución de SpecFlow que ejecutará la definición del paso que coincide con el paso del escenario.

• La coincidencia se realiza en tiempo de ejecución, por lo que las pruebas generadas se pueden compilar y ejecutar incluso si el enlace aún no está implementado.

• Puede incluir tablas y argumentos de varias líneas en los pasos del escenario. Estos son utilizados por las definiciones de pasos y se pasan como argumentos adicionales de tabla o cadena.

Etiquetas

Las etiquetas son marcadores que se pueden asignar a funciones y escenarios. Asignar una etiqueta a una característica es equivalente a asignar la etiqueta a todos los escenarios en el archivo de características. Un nombre de etiqueta con una @ inicial indica una etiqueta.

• Si es compatible con el marco de pruebas unitarias, SpecFlow genera categorías a partir de las etiquetas.

• El nombre de la categoría generada es el mismo que el nombre de la etiqueta, pero sin la @ inicial.

• Puede filtrar y agrupar las pruebas que se ejecutarán utilizando estas categorías de pruebas unitarias. Por ejemplo, puede etiquetar pruebas cruciales con @important y luego ejecutar estas pruebas con más frecuencia.

Elementos de fondo

El elemento de idioma de fondo permite especificar una condición previa común para todos los escenarios en un archivo de características

• La parte de fondo del archivo puede contener uno o más pasos de escenarios que se ejecutan antes que cualquier otro paso de los escenarios.

• SpecFlow genera un método a partir de los elementos de fondo que se invoca a partir de todas las pruebas unitarias generadas para los escenarios.

Esquemas de escenarios

Los esquemas de escenarios se pueden utilizar para definir pruebas de aceptación basadas en datos. El esquema del escenario siempre consta de una especificación de plantilla de escenario (un escenario con marcadores de posición de datos que utilizan la sintaxis <placeholder>) y un conjunto de ejemplos que proporcionan valores para los marcadores de posición.

• Si el marco de pruebas unitarias lo admite, SpecFlow genera pruebas basadas en filas a partir de esquemas de escenarios.

• De lo contrario, genera un método lógico de prueba unitaria parametrizado para un esquema de escenario y un método de prueba unitaria individual para cada conjunto de ejemplos.

• Para una mejor trazabilidad, los nombres de los métodos de prueba unitaria generados se derivan del título del esquema del escenario y del primer valor de los ejemplos (primera columna de la tabla de ejemplos).

• Por lo tanto, es una buena práctica elegir un parámetro único y descriptivo como primera columna del conjunto de ejemplos.

• Como la sintaxis de Gherkin requiere que todas las columnas de ejemplo tengan marcadores de posición coincidentes en el esquema del escenario, incluso puede introducir una columna arbitraria en los conjuntos de ejemplo utilizados para nombrar las pruebas con más legibilidad.

• SpecFlow realiza la sustitución del marcador de posición como una fase separada antes de hacer coincidir los enlaces de paso.

• La implementación y los parámetros en los enlaces de pasos son, por lo tanto, independientes de si se ejecutan a través de un escenario directo o un esquema de escenario.

• Esto le permite especificar más adelante ejemplos en las pruebas de aceptación sin cambiar los enlaces de pasos.

Comentarios

Puede agregar líneas de comentarios a los archivos de características en cualquier lugar comenzando la línea con #. Sin embargo, tenga cuidado, ya que los comentarios en su especificación pueden ser una señal de que los criterios de aceptación se han especificado incorrectamente. SpecFlow ignora las líneas de comentarios.