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 ayudarme a encontrar respuestas o guiar mis pensamientos :)

SpecFlow es muy útil para BDD en .NET. Pero cuando hablamos de BDD, ¿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 unitarias, SpecFlow mejora la documentación del código y el pensamiento en términos de lenguaje. Converseley, no puedo ver el código completo de una prueba en un solo lugar, ya que los pasos están fragmentados.

Ahora te ..........

EDIT: se me olvidó mencionar que veo RSpec en la comunidad RoR que utiliza la sintaxis de estilo BDD para las pruebas unitarias.

Answer 1

Recientemente comencé a usar SpecFlow para mi prueba de BDD, pero también uso pruebas de unidades y de integración.

Básicamente, he dividido las pruebas en proyectos separados:

• Especificaciones
• Integración
• Unidad

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

Utilizo BDD para describir pruebas que imitan los requisitos comerciales/de dominio de el proyecto. Por ejemplo, tendría especificaciones para la característica de generación de factura de un proyecto; o para trabajar con una cesta de la compra. Estas pruebas siguen el

Como usuario, quiero, Con el fin de

tipo de semántica.

Mi consejo es dividir las pruebas según sus necesidades. Evite tratar de realizar pruebas unitarias utilizando SpecFlow.

Answer 2

Lo veo como una prueba de integración que significa que no reemplaza los casos de prueba de la unidad escritos como parte de su proceso TDD. Alguien tendrá una opinión diferente sobre esto. El caso de prueba de la unidad de IMHO solo prueba 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. Podría hacer las mismas pruebas de integración con cualquiera de los marcos de prueba de la unidad, pero el BDD le brinda una manera más clara de explicar el caso de uso de la prueba de integración en un lenguaje específico del dominio que es un inglés sencillo (o cualquier idioma localizado).

Ta,
Rajeesh

Answer 3

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

Ahora supongo que si el equipo estuviera disperso y el desarrollador no pudiera ejecutar la aplicación completa, entonces sería necesario realizar pruebas de unidad separadas, pero el desarrollador tiene acceso a toda la base de códigos y puede ejecutar el aplicación, entonces ¿por qué molestarse en escribir más pruebas.

Answer 4

Utilicé el flujo de especificaciones para la prueba de BDD en dos aplicaciones diferentes de buen tamaño. Una vez que resolvimos los problemas de las convenciones de nomenclatura de oraciones, funcionó bastante bien. BA's y QA's, e incluso pasantes 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, hubo MUCHAS buenas razones para ello. El sistema fue responsable de hacer muchos cálculos o determinaciones basadas en una gran cantidad de datos diferentes. Con muchas pruebas unitarias que requieren que todos estos datos sean ingresados ​​para fines de prueba, hace que sea mucho más fácil administrar los datos usados ​​para las pruebas unitarias a través del formato de tabla provisto por specflow. Efectivamente burlarse del repositorio de datos en formato de tabla, permitiendo que los diferentes componentes sean probados enérgicamente.

No sé si lo haría en todos los casos, pero en los que lo utilicé, hizo que los volúmenes de datos necesarios para realizar las pruebas unitarias fueran mucho más fáciles y claros.

Answer 5

Hemos comenzado a usar Specflow incluso para nuestras pruebas unitarias.

La razón principal (y el beneficio) para esto es que encontramos que te obliga a escribir las pruebas desde un punto de vista del comportamiento, lo que a su vez te obliga a escribir de una manera más independiente de la implementación y esto finalmente resulta en pruebas que son menos frágiles y más fáciles de refabricación.

Claro, esto también se puede hacer con los marcos de prueba de unidades estándar, pero no se lo guía de la misma manera tan fácil como hemos descubierto que estamos usando specflow y la sintaxis de pepinillo.

Hay algunos ajustes generales para el flujo de especificaciones, pero encontramos que esto se amortiza rápidamente cuando se realizan algunas pruebas (debido a la importante reutilización de pasos que se puede obtener con el flujo de especificaciones) o se necesita refactorizar la implementación.

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

Answer 6

Dado:

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

Por lo tanto:

• Es evidente que las pruebas unitarias normalmente deben ser escritas en el lenguaje de programación que los usuarios de la “unidad de código” estarán llamando con.

Sin embargo:

• A veces se necesitan tablas de datos para configurar las condiciones de una prueba de unidad ejecuta en
• La mayoría de los frameworks de pruebas unitarias no son buenos en el uso de tablas de datos..

Por lo tanto:

• Specflow puede ser la mejor opción para algunos prueba de unidad, pero no debe ser su defecto elegir.