La última vez que busqué un framework fue a finales de 2009, ahora quiero usar BDD y descubro que hay aproximadamente 7 frameworks para BDD en .NET Me preguntaba si, según la experiencia de alguien, ¿cuál es el más maduro?Framework BDD (Desarrollo conducido por comportamiento) maduro para .net yC#
SpecFlow está emergiendo como una de las mejores herramientas .NET BDD, es cierto, y MSpec es excelente a nivel de unidad aunque no he encontrado mucho beneficio sobre NUnit, dada la naturaleza no técnica de la audiencia.
En serio, sin embargo, BDD no se trata de las herramientas. Si desea comenzar, concéntrese primero en las conversaciones en torno a los escenarios. Aquí es donde suceden las grandes ganancias en BDD, cuando las conversaciones comienzan a generar comprensión y más ideas sobre cómo resolver el problema y entregar el valor real del proyecto. Si las partes interesadas de su empresa desean involucrarse más en esas conversaciones, ese es un buen momento para comenzar a utilizar las herramientas BDD en inglés. De lo contrario, reconozca que esas herramientas introducen otra capa de abstracción, junto con la dificultad de refactorizar el inglés, determinar qué pasos ya no se usan, etc. Las herramientas BDD presentan otra capa de complejidad para la automatización de escenarios, que ya es complicada.
Si solo desea obtener más información acerca de cómo se combinan los marcos BDD, en lugar de utilizarlos en un proyecto empresarial, intente hacerlo.
Como alternativa, puede capturar los escenarios en un pequeño DSL personalizado, y hacer todo lo que necesita en el antiguo NUnit. Soy uno de los desarrolladores originales de JBehave y todavía no pasaría automáticamente a JBehave sin una buena razón y con un gran compromiso de las partes interesadas. Es fácil pasar a herramientas BDD en inglés más tarde una vez (¡si!) Se convierte en lo más útil.
No estoy 100% seguro de lo que estás buscando, pero SpecFlow es uno de los mejores frameworks BDD que he visto. El código está muy bien hecho y tiene mucha actividad en torno al esfuerzo de desarrollo.
Creo que SpecFlow es increíble, pero para mí dejó un agujero en el proceso de BDD: pruebas unitarias.
Así que ahora estoy buscando una solución "Total BDD" y planeo usar MSpec para "pruebas unitarias" (lea las especificaciones de contexto).
Al principio MSpec puede parecer un poco raro, pero no lleva mucho tiempo acostumbrarse.
Estoy totalmente de acuerdo con los comentarios de Lunivore sobre desistir del paso a las herramientas BDD hasta que esté listo. Resuena con mi experiencia. Si bien las herramientas son importantes, a veces puede ser un obstáculo. Y hay mucho que puede obtener de BDD sin adoptar ningún marco.
He escrito mis pensamientos aquí:
http://neelnarayan.blogspot.com/2011/04/bdd-is-not-about-tools.html
realmente no he utilizado specflow pero mi impresión es que hay bastante por encima! Tienes que decir todo tres veces. En el archivo de especificaciones, como una expresión regular para analizar y un método con el mismo nombre que la línea que se analiza.https://github.com/davidmfoley/storevil/wiki parece mucho más magra
Por ejemplo, con el fin de que coincida con lo siguiente:
Given I have a savings account with $100
En SpecFlow, y de manera similar en Pepino (ignorando las diferencias lingüísticas entre C# & Rubí), podría escribir algo como esto :
[Given(@"I have a (\w+) account with $(.*)")]
public void GivenIHaveAccount(string type, decimal amount) { ... }
en StorEvil, se puede utilizar una sintaxis similar a la anterior, O, puede escribir en la forma siguiente:
public void Given_I_Have_A_accountType_Account_with_amount(string accountType, decimal amount) { ... }
Concordion.NET es un marco agradable que permite BDD in plain English. Como está basado en html, puede usar la expresividad de la web para describir el producto de software desde la perspectiva del cliente. No depende de la coincidencia de patrones, sino que usa un small set of commands (por ejemplo, "establecer", "ejecutar", "assertEquals") para convertir ejemplos concretos dentro de los documentos html en pruebas de aceptación automatizadas. Por lo tanto, es muy adecuado para Specification by Example.
Estoy de acuerdo con esto, y el sentimiento se reitera en el último Hanselminutes # 248 (Especificaciones ejecutables). Ese sentimiento es que BDD es una herramienta que debe involucrar tanto al cliente/experto de dominio como al desarrollador. No le diría a su cliente "nos especializamos en comunicación telefónica, no se comunique con nosotros por correo electrónico o cara a cara". Es decir, debe elegir la herramienta con la que el cliente esté satisfecho y la que mejor se adapte al idioma del dominio. –