¿Cómo hago las pruebas de unidad e integración en un estilo BDD en ASP.NET MVC?

Question

Estoy aprendiendo Desarrollo impulsado por comportamiento con ASP.NET MVC y, basado en a post de Steve Sanderson, entiendo que BDD puede significar, al menos, los siguientes tipos de prueba: unidades individuales de código & UI interacciones. Algo similar se menciona en this post. ¿Necesito dos marcos de prueba diferentes si deseo ambas pruebas de integración y unidad?

• repositorios Unidad de prueba, controladores, & servicios utilizando un marco de contexto/especificación, como MSpec. Los resultados de las pruebas con esto serán útiles para el equipo de desarrollo.

• Prueba de comportamientos completos (integración) utilizando un marco determinado/cuándo/entonces, como SpecFlow con Watin. Los resultados de esta prueba serán útiles para mi cliente.

Los videos que he visto hasta ahora en el uso de BDD sólo se han limitado a probar el comportamiento de las entidades sin probar el comportamiento de los repositorios, controladores, etc ... ¿Hay un proyecto de ejemplo en el que puedo ver tanto ¿Pruebas automatizadas de unidad e integración usando un enfoque BDD?

Answer 1

Personalmente utilizo SpecFlow para crear pruebas específicas de la función (es decir, "El usuario crea un nuevo registro de la compañía") donde a veces (pero no siempre) uso Watin. Para probar mis respositorios o clases de servicio, usaré pruebas de unidad/integración con NUnit. Las pruebas de integración son para cuando necesito hablar con la base de datos durante la prueba, la unidad es para cuando simplemente ejecuto código en el objeto de destino bajo prueba sin interacciones externas.

Yo diría que no necesita usar un marco de BDD para sus pruebas de no UI. Puedes hacerlo si quieres, pero no hay una regla dura y rápida sobre esto. Si va a hacer esto, le recomiendo crear más de un proyecto para sus pruebas. Mantenerlos divididos es una buena idea, en lugar de mezclar toda la prueba en un solo proyecto. Se podría nombrarlos:

MyProject.Tests.Features < - para BDD pruebas SpecFlow.

MyProject.Tests.Integration < - Para pruebas que acceden a un recurso externo , es decir, una base de datos.

MyProject.Tests.Unit

Si no está queriendo utilizar dos marcos con TDC, todavía se puede utilizar MSTest/NUnit de una manera BDD. Por ejemplo, el artículo de blog this describe una buena convención de nomenclatura que está cerca de BDD, pero dirigida a pruebas de unidad MSTest/NUnit. Puede usar esto para sus pruebas que no sean SpecFlow cuando pruebe cosas como repositorios.

En resumen: no tiene que usar SpecFlow y MSpec en sus pruebas, pero si lo hace, entonces le recomiendo que realice proyectos de prueba por separado.

Answer 2

Generalmente estoy de acuerdo con lo que Jason publicó.

Es posible que desee dividir sus especificaciones en dos categorías, sistema/integración y pruebas de nivel de unidad. Puede describir ambas categorías con cualquier marco, pero tenga en cuenta que los enfoques solo de código (NUnit, MSpec, etc.) requieren que un analista de negocios sea capaz de escribir C#. SpecFlow/Gherkin puede ser un mejor enfoque si desea involucrar a analistas y usuarios en la redacción de especificaciones.Dado que la sintaxis y las reglas (Given, When, Then) son fáciles de entender y escribir las especificaciones desde la perspectiva de un usuario son fáciles de anotar después de un poco de entrenamiento. Se trata de cerrar la brecha de comunicación y hacer que los usuarios ayuden a su equipo a formar el lenguaje ubicuo de su dominio.

Recomiendo que las especificaciones sean compatibles tanto para trabajar "afuera adentro" como "adentro afuera". Puede comenzar con una especificación SpecFlow "externa" escrita por el usuario/analista/propietario del producto y trabajar desde "no implementada" hasta "verde" escribiendo el código real. El código que soporta la función se desarrolla usando TDD con un marco más orientado técnicamente como MSpec (la parte "al revés").

Aquí hay un repositorio que usa MSpec para las pruebas de unidad y de integración: https://github.com/agross/duplicatefinder.