bdd - tutorial - specflow net core

SpecFlow/BDD para pruebas unitarias?

Question

Parece que Internet no tiene una respuesta definitiva, o un conjunto de principios que me ayuden a responder la pregunta. Así que me dirijo a la gran gente de SO para que me ayude a encontrar respuestas o pensamientos de guía :)

SpecFlow es muy útil para BDD en .NET. Pero cuando hablamos de BDD, ¿simplemente estamos hablando de pruebas de integración / aceptación, o también estamos hablando de pruebas unitarias, un reemplazo total para TDD?

Solo lo he usado en proyectos pequeños, pero me parece que incluso para mis pruebas de unidad, SpecFlow mejora la documentación del código y el pensamiento en términos de idioma. Converseley, no puedo ver el código completo de una prueba en un solo lugar, ya que los pasos están fragmentados.

Ahora a ti ..........

EDITAR: Olvidé mencionar que veo RSpec en la comunidad RoR que usa la sintaxis de estilo BDD para las pruebas de unidad.

Answer 1

Al final, estamos tratando de entregar al cliente exactamente lo que el cliente quiere y, como tal, realmente no veo la necesidad de escribir pruebas unitarias además de SpecFlow. Después de todo, ejerce el mismo código base. Soy bastante nuevo en BDD/ATDD/TDD pero aparte de estar "completo" y de BDD/ATDD/TDD estrictamente a TDD, me parece innecesario escribir más pruebas unitarias.

Ahora, supongo que si el equipo estuviera disperso y el desarrollador no pudiera ejecutar la aplicación completa, serían necesarias pruebas unitarias separadas, pero donde el desarrollador (s) tenga acceso a todo el código base y pueda ejecutar la aplicación, entonces ¿por qué? molesta escribir más pruebas.

Answer 2

Hemos empezado a utilizar Specflow incluso para nuestras pruebas unitarias.

La principal razón (y beneficio) para esto es que encontramos que te obliga a escribir las pruebas desde un punto de vista de comportamiento, lo que a su vez te obliga a escribir de una manera más independiente de la implementación y esto en última instancia da como resultado pruebas que son menos Frágil y más refactorizante.

Claro que esto también se puede hacer con marcos de prueba de unidad estándar, pero no se te guía de esa manera tan fácilmente como hemos descubierto que estamos utilizando el flujo de especificaciones y la sintaxis de pepinillo.

Existen algunos ajustes generales para el flujo de especificaciones, pero encontramos que esto se repaga rápidamente cuando tiene bastantes pruebas (debido a la reutilización de pasos significativos que puede obtener con el flujo de especificaciones) o necesita refactorizar su implementación.

Además, obtiene buenas especificaciones legibles que son fáciles de entender para los recién llegados al equipo.

Answer 3

Lo veo como una prueba de integración, lo que significa que no reemplaza sus casos de prueba de unidad escritos como parte de su proceso de TDD. Alguien tendrá una opinión diferente sobre esto. En mi caso de prueba de unidad IMHO solo se prueban los métodos / funciones y todas las dependencias deben ser burladas e inyectadas. Cuando se trata de pruebas de integración, inyectará dependencias reales en lugar de una burlada. Puede realizar la misma prueba de integración con cualquiera de los marcos de prueba de unidad, pero el BDD le proporciona una forma más clara de explicar el caso de uso de la prueba de integración en un idioma específico del dominio que es un inglés sencillo (o cualquier idioma localizado).

Ejército de reserva,
Rajeesh

Answer 4

Utilicé el flujo de especificaciones para las pruebas de BDD en dos aplicaciones de buen tamaño diferentes. Una vez que trabajamos a través de los problemas de las convenciones de nomenclatura de oraciones, funcionó bastante bien. Licenciados y control de calidad, e incluso los internos podrían escribir pruebas BDD para la aplicación.

Sin embargo, también lo usé para pruebas unitarias. ¡Herejía! Puedo escuchar a algunos de ustedes gritar. Sin embargo, había MUY buenas razones para ello. El sistema fue responsable de realizar muchos cálculos o determinaciones basadas en una gran cantidad de datos diferentes. Con muchas pruebas unitarias que requieren que todos estos datos se ingresen para fines de prueba, hace que sea MUCHO más fácil administrar los datos utilizados para las pruebas unitarias a través del formato de tabla provisto por el flujo de especificaciones. Se burlan efectivamente del repositorio de datos en formato de tabla, lo que permite que los diferentes componentes se prueben vigorosamente.

No sé si lo haría en todos los casos, pero en los que lo utilicé, hizo que la disposición de los volúmenes de datos necesarios para realizar las pruebas unitarias fuera mucho más fácil y clara.

Answer 5

Dado:

• Las pruebas unitarias son pruebas de (pequeñas) "unidades de código"
• El cliente de la mayoría de las "unidades de códigos" son otros programadores.
• Parte de la razón para tener una prueba de unidad es proporcionar un ejemplo de cómo llamar al código.

Por lo tanto:

• Evidentemente, las pruebas unitarias normalmente deben escribirse en el lenguaje de programación con el que los usuarios de la "unidad de código" lo llamarán.

Sin embargo:

• A veces, se necesitan tablas de datos para configurar las condiciones en que se ejecuta una prueba unitaria.
• La mayoría de los marcos de prueba de unidad no son buenos para usar tablas de datos.

Por lo tanto:

• Specflow puede ser la mejor opción para algunas pruebas unitarias, pero no debe ser su elección predeterminada.

Answer 6

Recientemente comencé a usar SpecFlow para mis pruebas de BDD, pero también sigo usando pruebas de unidad e integración.

Básicamente, dividí las pruebas en proyectos separados:

• Especificaciones
• Integración
• Unidad

Mis pruebas unitarias son para probar un solo método y no realizan ninguna llamada a la base de datos, ni referencias externas de ningún tipo. Utilizo pruebas de integración para llamadas a un solo método (quizás dos) que interactúan con recursos externos, como una base de datos, un servicio web, etc.

Utilizo BDD para describir pruebas que imitan los requisitos de negocio / dominio del proyecto. Por ejemplo, tendría especificaciones para la función de generación de facturas de un proyecto; o para trabajar con una cesta de la compra. Estas pruebas siguen la

Como usuario, quiero, con el fin de

Tipo de semántica.

Mi consejo es dividir sus pruebas según sus necesidades. Evite intentar realizar pruebas unitarias usando SpecFlow.