Estoy interesado en Behavior Driven Development (BDD)¿Qué Herramientas/marcos de desarrollo impulsado por comportamiento (BDD) están disponibles para Microsoft Stack?
¿Existen buenos frameworks y/o herramientas disponibles para la plataforma .Net (preferiblemente C# y ASP.Net)?
¿Y cuándo ha demostrado que el BDD es más apropiado para usar en escenarios del mundo real? (pregunta auxiliar)
En google encontré Behavior Driven Development (BDD) with SpecFlow and ASP.NET MVC. Puede encontrarlo útil, eche un vistazo. También ir a través Behavior-Driven Development with SpecFlow and WatiN
Una buena presentación en Pros and Cons of BDD
Un canal 9 de vídeo Behavior-Driven Development in the Real World
y por último pero no menos importante un artículo InfoQ Behavior Driven Development In .NET
también MSpec es un buen marco.
Lo uso en la pila de Microsoft que menciona (C#, ASP.Net y MVC) y me gusta su sintaxis.
BDD le ayuda a pensar de forma orientada a los negocios/funciones, no solo en forma de código. Así que está más centrado en el valor comercial.
También ayuda en la prueba de aceptación del usuario crear una confianza entre usted y el cliente.
Hay una gran herramienta, llamada SpecFlow. SpecFlow está inspirado en Cucumber, el conocido marco BDD para Ruby on Rails. Y tiene una gran cantidad de ventajas.
Debería echarle un vistazo.
Háblame de eso, por favor. –
+1 para la recomendación de la gente de SpecFlow para escenarios; nunca lo usé, pero escuché muchas cosas buenas al respecto. He estado usando el viejo NUnit simple con un pequeño DSL como this. MSTest funcionaría de manera similar.
Usted puede también hacer BDD en el espacio de la unidad, que es lo que MSpec está diseñado para hacer. Personalmente estoy odiando MSpec, pero el resto del equipo aquí lo ama. Les gusta escribir ejemplos de cómo funciona el código. Me gusta mostrar por qué el comportamiento es valioso. Es una distinción sutil y si no te preocupa hacer esto a nivel de unidad, no te golpeará.
Otros marcos a considerar incluyen Concordion, Fitnesse.NET (¡por favor ponga FitSharp detrás de esto!) Y TickSpec.
En el mundo real, el bit más valioso de BDD por mucho tiempo es el conversaciones, no las pruebas automatizadas. He aquí un par de consejos rápidos y consejos para hacer que funcione:
No escribir pruebas automatizadas sobre las cosas que están en proceso de cambio. Simplemente te compromete con cosas que obtuviste mal. Espere hasta que la interfaz de usuario se haya asentado un poco y luego hágalo.
Si no le importa mucho la interfaz de usuario, pero le importa la integridad de los datos, escriba los escenarios sobre la capa de controlador/presentador (por ejemplo, para las pantallas de administración).
No comience con el inicio de sesión. Comience describiendo una parte valiosa de la aplicación para la que puede iniciar sesión. Haga eso primero (suponiendo que solo tiene un usuario). Obtendrá comentarios más rápidos sobre los bits arriesgados.
Busque comentarios rápidos sobre los bits riesgosos, que generalmente serán los bits que nunca ha hecho antes. Usa escenarios para tener conversaciones a su alrededor. Escribe cualquier cosa interesante que descubras, pero olvida los escenarios que son obvios, ¡son obvios! No se preocupe por automatizarlos para empezar. Tener conversaciones es más importante que escribir conversaciones es más importante que automatizar las conversaciones.
¡Buena suerte! Si quiere saber más acerca de BDD, reúno una página de enlaces relevantes here.
Esto es un poco más como lo que estaba buscando. +1 –
Un marco BDD interesante es Concordion.NET. Es un marco de BDD de código abierto para la pila de Microsoft que usa NUnit para ejecutar las pruebas de Concordion.NET: https://github.com/concordion/concordion-net Como las especificaciones de Concordion están escritas en HTML simple, proporcionan una buena base para un sistema de documentación en vivo. Puede usar un editor WYSIWYG (WYSIWYG) como lo que usted ve, para describir el comportamiento previsto de su software en documentos HTML sencillos e instrumentarlos para verificar su sistema bajo prueba. De acuerdo con excellent classification of BDD tools, Concordion.NET se enfoca en la entrada legible por negocios (y también alcanza la salida legible por negocios). Se mueve incluso más allá de BDD y es compatible con ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/
Spec4Net (https://bitbucket.org/fthomsen/spec4net/) es un buen marco también. Lo usamos ampliamente en el trabajo. La curva de aprendizaje es casi inexistente y el flujo natural parece intuitivo.
LightBDD es un marco de código abierto que permite escribir pruebas de BDD que son fáciles de leer pero también fáciles de mantener y ampliar cuando el proyecto crece.
Las principales características que ofrece son:
Se basa en pruebas que están escritas puramente en código, lo que significa soporte nativo para refactorización, análisis de código, ejecución de prueba y todas las demás características que Visual Studio/Intellisense/Resharper ofrece.
Una prueba de ejemplo escrito en este marco se ve de la siguiente manera:
[TestFixture]
[FeatureDescription(
@"In order to access personal data
As an user
I want to login into system")] //feature description
[Label("Story-1")]
public partial class Login_feature //feature name
{
[Test]
[Label("Ticket-1")]
public void Successful_login() //scenario name
{
Runner.RunScenario(
Given_user_is_about_to_login, //steps
Given_user_entered_valid_login,
Given_user_entered_valid_password,
When_user_clicked_login_button,
Then_login_is_successful,
Then_welcome_message_is_returned_containing_user_name);
}
}
Más información acerca de marco se puede conocer en project wiki page y project main page.
Gracias Haris, pero cualquiera puede Google y devolver enlaces de artículos. Espero escuchar algunas experiencias profesionales de los desarrolladores y lo que saben sobre estos marcos.Si sabe más acerca de SpecFlow, por favor hágamelo saber. –
No puedo recomendar SpecFlow y WatiN suficiente, ¡una combinación brillante! –