que - ¿Cuál es el marco de BDD más maduro para.NET?
specflow que es (13)
Hemos estado usando BDD - Behavior Driven Development (desde la perspectiva de Dan North) como un mecanismo para registrar las pruebas de aceptación de los usuarios e impulsar el desarrollo en un par de proyectos, con un éxito decente. Hasta la fecha, aunque 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 ver? ¿Hay un claro ''ganador'' en este momento?
La respuesta rapida
Un punto muy importante que se debe mencionar es que existen dos tipos de desarrollo impulsado por el comportamiento. Los dos sabores son xBehave y xSpec .
xBehave BDD: SpecFlow
SpecFlow (muy similar al cucumber de la pila de Ruby) es excelente para facilitar las pruebas BDD de xBehave 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
Objetivamente hablando. Dados los marcos de especificaciones de contexto disponibles, MSpec ha estado alrededor del más largo y es el marco de especificación / contexto más utilizado en la comunidad .Net.
El otro marco de BDD xSpec: NSpec
Personalmente recomendaría NSpec (inspirado directamente por RSpec para Ruby). Revelación completa, soy uno de los autores de NSpec. Puedes lograr BDD simplemente usando NUnit o MSTest ... pero se quedan cortos (es muy difícil construir contextos de manera incremental). MSpec también es una opción y es el marco de especificación / contexto más maduro para .Net. 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 (por ejemplo, Dado ..., Y Dado ..., Cuando ... y Cuando ..., Entonces ... Y entonces)
- el dialecto común puede asignarse 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 debe desambiguar los requisitos y hacer que se ajuste a las oraciones.
Contras
- Si bien el enfoque xBehave es bueno para impulsar los criterios de aceptación de alto nivel, los ciclos necesarios para asignar el inglés al código ejecutable a través de los atributos hacen que sea imposible expulsar un dominio a nivel de unidad.
- El mapeo del dialecto común a las pruebas es DOLORABLE (acelere en su expresión regular). Cada oración que crea la empresa debe asignarse a un método ejecutable a través de atributos.
- El dialecto común debe controlarse estrechamente para que la administració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 el contexto de manera incremental. Se puede configurar un contexto para una prueba y se pueden realizar algunas aserciones contra ese contexto. Luego puede especificar más contexto (basándose en el contexto que ya existe) y luego especificar más pruebas.
- Sin lenguaje constrictor. Los desarrolladores pueden ser más expresivos sobre cómo se comporta una determinada parte de un sistema.
- No se necesita mapeo entre el inglés y un dialecto común (porque no hay uno).
Contras
- No es tan accesible por el negocio. Seamos realistas, a la empresa no le gusta desambiguar lo que quieren. Si les damos un enfoque basado en el contexto a la BDD, entonces la oración simplemente diría "Solo haz que funcione".
- Todo está en el código. La documentación del contexto está interconectada dentro del código (por eso no tenemos que preocuparnos de asignar el inglés al código)
- No es tan legible dado un verborrea menos restrictivo.
Muestras
El Bowling Kata es un buen ejemplo.
Muestra SpecFlow
Aquí es cómo se vería la especificación en SpecFlow (nuevamente, esto es excelente como prueba de aceptación, porque se comunica directamente con el negocio)
Archivo de característicasEl archivo de características es el dialecto común para la prueba.
Feature: Score Calculation In order to know my performance As a player I want the system to calculate my total score Scenario: Gutter game Given a new bowling game When all of my balls are landing in the gutter Then my total score should be 0 Scenario: Single Pin Given a new bowling game When I''ve hit exactly 1 pin Then my total score should be 1 Archivo de definición de pasos
El archivo de definición de pasos es la ejecución real de la prueba, este archivo incluye las asignaciones para SpecFlow
[Binding]
public class BowlingSteps
{
private Game _game;
[Given(@"a new bowling game")]
public void GivenANewBowlingGame()
{
_game = new Game();
}
[When(@"all of my balls are landing in the gutter")]
public void WhenAllOfMyBallsAreLandingInTheGutter()
{
_game.Frames = "00000000000000000000";
}
[When(@"I''ve hit exactly 1 pin")]
public void When1PinIsHit()
{
_game.Frames = "10000000000000000000";
}
[Then(@"my total score should be (/d+)")]
public void ThenMyTotalScoreShouldBe(int score)
{
Assert.AreEqual(score, _game.Score);
}
}
Ejemplo de MSpec, Especificación x, Contexto / Especificación
public class describe_BowlingKata
{
public static Game game;
public class when_all_balls_land_in_the_gutter : describe_BowlingKata
{
Establish ctx = () => game = new Game();
Because of = () => game.Frames = "00000000000000000000";
It should_have_a_score_of_0 = () => game.Score.ShouldBe(0);
}
public class when_a_single_pin_is_hit : describe_BowlingKata
{
Establish ctx = () => game = new Game();
Because of = () => game.Frames = "10000000000000000000";
It should_have_a_score_of_1 = () => game.Score.ShouldBe(1);
}
}
Ejemplo de NSpec, espec. X, contexto / especificación
Aquí hay un ejemplo de NSpec de la misma kata de bolos:
class describe_BowlingGame : nspec
{
Game game;
void before_each()
{
game = new Game();
}
void when_all_my_balls_land_in_the_gutter()
{
before = () => game.Frames = "00000000000000000000";
it["should have a score of 0"] = () => game.Score.should_be(0);
}
void when_a_single_pin_is_it()
{
before = () => game.Frames = "10000000000000000000";
it["should have a score of 1"] = () => game.Score.should_be(1);
}
}
A medida que haga más y más BDD, descubrirá que se necesitan los sabores xBehave y xSpec de BDD. xBehave es más adecuado para pruebas de aceptación, xSpec es más adecuado para pruebas unitarias y diseño controlado por dominio.
MSpec vs NSpec
Las métricas objetivas como la edad y la estabilidad deberían ser un factor, y animaría a todos a tomar eso en consideración. Pero también tenga en cuenta que los marcos más nuevos pueden proporcionar una API más sucinta, un mejor uso de las construcciones de lenguaje y aprovechar las lecciones aprendidas de los marcos anteriores . MSpec proporciona construcciones de Given, Since, It y Cleanup ... pero tienen un costo: inicialización estática para todos los miembros, explosión de clase y es sintácticamente rígido debido a su uso exclusivo de delegados. Encontrará que las pruebas de MSpec más simples son más simples en NSpec. Aquí hay un conjunto de pruebas más complejo escrito tanto en MSpec como en NSpec.
Una comparación de xUnit, MSpec y NSpec: https://gist.github.com/amirrajan/6701522
Enlaces relevantes
Como ahora estoy tratando con BDD para pruebas de sistemas para aplicaciones críticas de seguridad, solo puedo compartir mi experiencia de que no debería 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 (consulte el ejemplo de flujo de especificaciones anterior) y lo hicimos bien. Además del hecho de que nunca expliqué la sintaxis a nadie, todos comprendieron de inmediato el significado de la prueba, el desarrollador, el administrador e incluso el probador.
De cualquier manera evitaría 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 Gherkin. Mientras más personas sean capaces de leer y modificar las pruebas, mejor.
Por último, pero no menos importante, estas pruebas son portátiles a cualquier otro lenguaje de programación, cualquier otra plataforma, cualquier otra herramienta de automatización de pruebas sin ningún cambio.
Una vez más, la respuesta es una vez más:
No se preocupe por la herramienta y sus características, 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 el uso de SpecFlow. Usted tiene acceso completo a la Biblioteca .Net completa y todas sus funciones, sus pruebas permanecen portátiles. Esto podría darle una ventaja sobre las 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 puede ser una buena idea (o incluso la mejor) en algunos casos.
Sin embargo, SpecFlow se mostró estable y a prueba de balas en las pruebas diarias, incluidas las pruebas de construcción nocturnas, etc. en proyectos de tamaño mediano. Además, se integra bien en el entorno de prueba de unidad de Microsoft.
Consulte esta publicación del blog y sus comentarios para obtener ideas inspiradoras: http://haacked.com/archive/2008/08/23/introducing-subspec.aspx/
Echa un vistazo a SpecFlow .
Es una herramienta inspirada en Cucumber que tiene como objetivo proporcionar un enfoque pragmático y sin fricción para el desarrollo guiado por pruebas de aceptación y el desarrollo guiado por comportamiento para los proyectos .NET de hoy.
La integración de VisualStudio parece especialmente prometedora.
Estoy empezando mi primera salida en BDD con una pequeña aplicación con mi equipo. Las herramientas que elegimos para hacer el trabajo son: Specflow con Selenium Webdriver para xBehave stories y MSpec con Machine.Fakes.Moq para un contenedor de automocking para nuestras pruebas de unidad de xSpec. Con Resharper será nuestro corredor de historia y nuestro corredor de especificaciones debido a la integración compatible con Specflow y MSpec. Tener una integración nativa en Visual Studio con R # es una característica clave para nosotros.
Como nuestro diseño es todo MVC3, también aplicaremos el patrón de separación del orquestador a nuestros controladores MVC . Esto nos permitirá escribir especificaciones directamente contra el orquestador. Luego, para que escribamos historias directamente en contra del uso de nuestra aplicación.
No creo que haya un ''ganador'' realmente. Otros marcos incluyen el proyecto SpecUnit.NET y MSpec también se muestra prometedor con los inicios de un adaptador Gallio . Desde el punto de vista técnico, ya que IronRuby está en el horizonte, rSpec puede ser una opción para aquellos que están preparados para salir a rSpec . NBehave + NSpec podría ser el marco más antiguo con la mejor automatización, aunque me encontré luchando contra la sintaxis demasiado verbosa.
Los revisaría todos y elegiría el marco que mejor se adapte a su estilo de proyectos. Todos son OSS, por lo que es difícil de perder, el beneficio real es simplemente pasar a BDD.
Personalmente recomendaría BDDfy que es genial en mi opinión! Es de código abierto, es compatible con la convención y la descripción de escenarios basada en fluidez, cubre grandes pruebas tanto de aceptación como de unidad. Lo puedes encontrar en GitHub .
Por lo general, preferiría NBehave, combinado con MbUnit y los marcos de simulación / DI que necesite. Es un comentario justo de Jim Burger que NBehave es muy detallado, y a veces me encuentro cortando y pegando. Aún así, funciona muy bien. Estoy usando el complemento ReSharper de Gallio, así que solo aparece una ventana adicional. Aún no lo he probado con ccnet.
También está Specter , que define un DSL en Boo para hacerlo todo más natural.
También puedes ver UBADDAS, específico de UAT encontrado 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
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 le obliga a utilizar una cierta sintaxis, sino que utiliza un enfoque basado en palabras clave. Si está probando aplicaciones web, tiene Selenium2Library que proporciona enlaces a Selenium WebDriver.
StoryQ parece una buena alternativa a NBehave con su interfaz Fluent. Definitivamente lo comprobaría.
Concordion.NET no solo es compatible con BDD sino también con ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/ especificaciones están escritas en un lenguaje sencillo utilizando 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 vivo . Y, dado que las pruebas se ejecutan en el sistema, puede estar seguro de que la documentación está siempre actualizada.