¿Cuál es el marco BDD más maduro para .NET? [cerrado]

StackOverflow https://stackoverflow.com/questions/307895

  •  08-07-2019
  •  | 
  •  

Pregunta

Hemos estado utilizando BDD - Behavior Driven Development (desde la perspectiva de Dan North) como mecanismo para grabar pruebas de aceptación del usuario e impulsar el desarrollo en un par de proyectos, con un éxito decente. Hasta la fecha, no hemos automatizado las pruebas en sí.

Ahora estoy buscando automatizar las pruebas, pero no estoy seguro de qué marco de comportamiento respaldar. Hasta ahora, NBehave parece ser el precursor, pero ¿hay otros que debería mirar? ¿Hay un claro "ganador" en este momento?

¿Fue útil?

Solución

La respuesta rápida

Un punto muy importante para mencionar es que hay dos sabores de Desarrollo Conducido por el Comportamiento. Los dos sabores son xBehave y xSpec .

xBehave BDD: SpecFlow

SpecFlow (muy similar a pepino de la pila Ruby) es excelente para facilitar las pruebas xBehave BDD como criterios de aceptación. Sin embargo, no proporciona una buena manera de escribir pruebas de comportamiento a nivel de unidad. Hay algunos otros marcos de prueba de xBehave, pero SpecFlow ha recibido mucha tracción.

xSpec BDD: MSpec

Hablando objetivamente. Dados los marcos de especificaciones de contexto disponibles, MSpec ha sido el más antiguo y es el marco de contexto / especificación más utilizado en la comunidad .Net.

El otro marco xSpec BDD: NSpec

Yo personalmente recomendaría NSpec (inspirado directamente en RSpec para Ruby). Divulgación completa, soy uno de los autores de NSpec. Puede lograr BDD simplemente usando NUnit o MSTest ... pero se quedan cortos (es realmente difícil construir contextos de forma incremental). MSpec también es una opción y es el marco de contexto / especificación más maduro para. Red. Pero , hay algunas cosas que son más simples en NSpec.

La respuesta larga

Los dos sabores de BDD existen principalmente debido a los beneficios ortogonales que proporcionan.

Pros y contras de xBehave (sintaxis GWT)

Pros

  • ayuda a facilitar las conversaciones con la empresa a través de un dialecto común llamado (p. ej., dado ..., y dado ..., cuándo ... y cuándo ..., entonces ... .., y luego)
  • el dialecto común se puede asignar a un código ejecutable que demuestre a la empresa que realmente terminó lo que dijo que terminaría
  • el dialecto es restrictivo, por lo que el negocio tiene que desambiguar los requisitos y adaptarlo a las oraciones.

Contras

  • Si bien el enfoque xBehave es bueno para conducir Criterios de aceptación de alto nivel, los ciclos necesarios para asignar el inglés al código ejecutable a través de atributos lo hacen inviable para expulsar un dominio a nivel de unidad.
  • Mapear el dialecto común a las pruebas es DOLOROSO (aumentar su expresión regular). Cada oración que crea la empresa debe asignarse a un método ejecutable mediante atributos.
  • El dialecto común debe controlarse estrictamente para que la gestión del mapeo no se salga de control. Cada vez que cambie una oración, debe encontrar un método que se relacione directamente con esa oración y corregir la coincidencia de expresiones regulares.

Pros y contras de xSpec (contexto / especificación)

Pros

  • Permite al desarrollador construir contexto de forma incremental. Se puede configurar un contexto para una prueba y se pueden realizar algunas aserciones en ese contexto. Luego puede especificar más contexto (basándose en el contexto que ya existe) y luego especificar más pruebas.
  • Sin lenguaje restrictivo. Los desarrolladores pueden ser más expresivos sobre cómo se comporta cierta parte de un sistema.
  • No se necesita mapeo entre el inglés y un dialecto común (porque no hay uno).

Contras

  • No tan accesible para la empresa. Seamos realistas, al negocio no le gusta desambiguar lo que quiere. Si les diéramos un enfoque de BDD basado en el contexto, la oración simplemente leería "Solo haz que funcione".
  • Todo está en el código. La documentación de contexto está entrelazada dentro del código (es por eso que no tenemos que preocuparnos de asignar el inglés al código)
  • No tan legible dado un menos restrictivo

Otros consejos

Consulte SpecFlow .

Es una herramienta inspirada en Cucumber que tiene como objetivo proporcionar un enfoque pragmático y sin fricciones para el desarrollo impulsado por pruebas de aceptación y el desarrollo impulsado por el comportamiento para los proyectos .NET en la actualidad.

La integración de VisualStudio parece especialmente prometedora.

StoryQ parece una buena alternativa a NBehave con su interfaz Fluent. Definitivamente lo verificaría.

No creo que haya un 'ganador' realmente. Otros marcos incluyen SpecUnit.NET proyecto y MSpec también se muestra prometedor con el principios de un Gallio adaptador. Técnicamente, dado que IronRuby está en el horizonte, rSpec puede ser una opción para aquellos preparados para ir al límite. NBehave + NSpec podría ser el marco más antiguo con la mejor automatización, aunque me encontré luchando contra la sintaxis demasiado detallada.

Los revisaría todos y elegiría el marco que mejor se adapte al estilo de sus proyectos. Todos son OSS, por lo que es difícil de perder, el beneficio real es simplemente mudarse a BDD.

¡Yo personalmente recomendaría BDDfy que es genial en mi opinión! Es de código abierto, admite la descripción de escenarios basada en fluidos y convenciones, cubre tanto la aceptación como las pruebas unitarias. Puede encontrarlo en GitHub .

Robot Framework también se puede usar con IronPython para hacer ATDD o BDD en .Net. Creo que las capacidades de expresión de Robot Framework son mejores que, por ejemplo. SpecFlow 's o NSpec ' s. No lo obliga a usar una determinada sintaxis, sino que utiliza un enfoque basado en palabras clave. Si está probando aplicaciones web, tiene Selenium2Library que proporciona enlaces a Selenium WebDriver.

También hay Spectre , que define un DSL en Boo para hacerlo más natural.

Por lo general, preferiría NBehave, combinado con MbUnit y cualquier marco DI / burlón que necesite. Es un comentario justo de Jim Burger que NBehave es muy detallado, y a veces me encuentro usando cortar y pegar. Aún así, funciona muy bien: estoy usando el complemento ReSharper de Gallio, así que solo aparece una ventana adicional. Sin embargo, aún no lo he probado con ccnet.

Consulte esta publicación de blog y sus comentarios para obtener ideas inspiradoras: http : //haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Concordion.NET no solo admite BDD sino también ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-atdd / Las especificaciones están escritas en inglés sencillo usando HTML. En mi humilde opinión, este es uno de los beneficios de Concordion.NET. Los documentos HTML se pueden organizar en una estructura navegable para construir un sistema de documentación viva . Y, dado que las pruebas se ejecutan contra el sistema, puede estar seguro de que la documentación siempre está actualizada.

Estoy comenzando mi primera salida en BDD con una pequeña aplicación con mi equipo. Las herramientas que estamos eligiendo para hacer el trabajo son: Flujo de especificaciones con Selenium Webdriver para xBehave historias y MSpec con Machine.Fakes.Moq para un contenedor de autobloqueo para nuestras pruebas unitarias xSpec. Con Resharper para ser nuestro corredor de historias y de especificaciones debido a la integración soportada por Specflow y MSpec. Tener una integración nativa en Visual Studio con R # es una característica clave para nosotros.

Dado que nuestro diseño es todo MVC3, también aplicaremos el patrón de separación del orquestador para nuestros controladores MVC . Esto nos permitirá escribir especificaciones directamente contra el orquestador. Luego, para que podamos escribir historias directamente en contra del uso de nuestra aplicación.

Dado que ahora estoy trabajando con BDD para pruebas de sistema para aplicaciones críticas de seguridad, solo puedo compartir mi experiencia de que no debe subestimar el poder de las pruebas escritas en un lenguaje natural. en lugar de " código " ;.

Siempre nos enfocamos en ofrecer un lenguaje de características, que cualquiera pueda entender sin ningún conocimiento técnico o experiencia en programación (vea el ejemplo de flujo de especificaciones anterior) y lo hicimos bien. Además del hecho de que nunca le expliqué la sintaxis a nadie, todos entendieron de inmediato el significado de la prueba, el desarrollador, el administrador e incluso el probador.

Evitaría de alguna manera una prueba escrita en un lenguaje de programación como los ejemplos de MSpec anteriores. Si me presento con una prueba como esta en la oficina de un gerente, él me echará. Pero está interesado en leer pruebas basadas en sintaxis de pepinillo. Cuantos más chicos puedan leer y modificar las pruebas, mejor.

Por último, pero no menos importante, esas pruebas son portables a cualquier otro lenguaje de programación, cualquier otra plataforma, cualquier otra herramienta de automatización de pruebas sin ningún cambio.

Nuevamente, la respuesta es una vez más:

No se preocupe por la herramienta y sus características en sí, elija una herramienta que le permita cambiar fácilmente a otra herramienta en cualquier momento sin perder información. Las herramientas van y vienen, mis pruebas deberían durar más. :-)

Puedo recomendar usar SpecFlow. Tiene acceso completo a la biblioteca .Net completa y todas sus características, sus pruebas se mantienen portátiles. Esto podría darle una ventaja sobre soluciones totalmente portátiles como Robot Framework, si no le importa la portabilidad. Sin embargo, siempre puede mejorar la estabilidad y la portabilidad de un sistema utilizando diferentes herramientas para el desarrollo y las pruebas. Por lo tanto, probar un software .Net con un enfoque BDD basado en Python podría ser una buena (o incluso la mejor) idea en algunos casos.

Sin embargo, SpecFlow se mostró estable y a prueba de balas en las pruebas diarias, incluidas las pruebas nocturnas de construcción, etc. en proyectos de tamaño mediano. Además, se integra bien en el entorno de prueba de unidad de Microsoft.

Consulte también UBADDAS, específico de UAT que se encuentra en

https://github.com/KernowCode/UBADDAS

con una explicación aquí

http://kernowcode.wordpress.com/ (en junio de 2014)

Puedes escribir una prueba como esta 

[Test]
public void IWantToRegisterANewUser()
{
  var user = new User();
  ICustomer customer = new Customer();

  SoThat(MyBusinessValue.IncreaseCustomerBase)
    .As(user)
    .Given(customer.Register)
    .When(customer.Confirm_Registration)
    .Then(customer.Login);
}

y produce esto 

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top