que - ATDD versus BDD y el uso adecuado de un marco
cucumber (5)
Acabo de entrar en el concepto de BDD y he escuchado la charla de Scott Bellware con los chicos del Código Herding. He estado jugando con SpecFlow un poco y me gusta bastante bien.
Entiendo la distinción entre ATDD y TDD como se describe en la publicación del blog Clasificando las herramientas de BDD (Unit-Test-Driven vs. Test de Driven Test) y un poco de la historia de BDD , pero eso me lleva a una pregunta.
Como se describe, ¿no está utilizando una herramienta BDD (como MSpec) simplemente otro marco de prueba de unidad? Me parece que lo es.
Además, esto parece sugerir que el uso de SpecFlow para especificar los componentes de nivel inferior (como sus repositorios y servicios) sería incorrecto. Si puedo usar la misma herramienta tanto para ATDD como para TDD de componentes de nivel inferior, ¿por qué no debería? Parece que todavía hay algunas líneas borrosas aquí que siento que no entiendo muy bien.
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: NSpec
Para el desarrollo basado en el comportamiento a nivel de unidad, recomendaría NSpec (inspirado directamente por RSpec para Ruby) . Puede lograr BDD a nivel de unidad 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, se ha realizado mucho trabajo, pero hay algunos que son simplemente más simples en NSpec (se puede crear un contexto de forma incremental en MSpec, pero requiere una herencia que puede volverse compleja).
La respuesta larga
Los dos tipos de BDD existen principalmente debido a los beneficios ortogonales que brindan.
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 Y cuando ... Entonces ... Y entonces)
- el dialecto común puede luego 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 atributos hacen que no sea factible eliminar 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.
- No hay 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. Afrontémoslo, a la empresa no le gusta cambiar la ambigüedad de lo que quiere. 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 la empresa):
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 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";
}
[Then(@"my total score should be (/d+)")]
public void ThenMyTotalScoreShouldBe(int score)
{
Assert.AreEqual(0, _game.Score);
}
}
Ejemplo de NSpec, espec. X, contexto / especificación
Aquí hay un ejemplo de NSpec del mismo 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);
}
}
Así que sí ... SpecFlow es genial, NSpec es genial
A medida que haga más y más BDD, encontrará que se necesitan tanto los sabores xBehave como 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.
Enlaces relevantes
Creo que su comprensión está en línea con la mía. BDD es más adecuado para pruebas de integración y generalmente prueba su sistema como usuario final, por ejemplo:
Given I am an authorised user
When I go to the front page
Then there should be a link to my profile with my username as the link text.
No hay razón para no hacer una prueba unitaria de sus repositorios a un nivel más granular. Creo que ambos son útiles y apropiados.
Es interesante que este blog en Classifying BDD Tools se refiera a TDD y ATDD. Como señala Liz Keogh: BDD se trata de conversación y exploración . Cuanto más fácil sea para todos los involucrados, contribuir, comunicar intenciones, compartir ideas, comprender a los demás, etc., más rápido llegaremos a una solución adecuada y el mejor software que construimos. Cuando finalmente seguimos el camino de la herramienta, ¿cuáles son las herramientas que mejor apoyan la colaboración entre los interesados en los proyectos de software?
Basado en este blog sobre las diferencias entre TDD, BDD y ATDD , diría que hay al menos tres tipos diferentes de herramientas BDD :
- Unidades de Pruebas Unitarias
JUnit cambió nuestra opinión sobre el desarrollo y las pruebas. Uno de sus puntos fuertes es que las pruebas se pueden escribir en el mismo lenguaje de programación que la aplicación en sí. Por lo tanto, podemos aprovechar el conocimiento que ya tenemos en el equipo de entrega. Cuando las pruebas incluso se utilizan para impulsar el desarrollo, llegamos al cielo de TDD.
Los lenguajes de programación se han optimizado para reducir la redundancia, lo que, según Ron Jeffries, es uno de los peores pecados de los desarrolladores. Por lo tanto, a menudo dependemos de estas herramientas cuando hacemos pruebas técnicas para construir el producto correctamente, ya que nos ayudan a ser más eficientes.
Varios muchachos intentaron hacer las pruebas automatizadas más comprensibles, ya que las pruebas unitarias no son realmente legibles . Uno de los primeros intentos fue analizar las pruebas unitarias y proporcionar un resumen conciso que también sea legible para los no desarrolladores. Por ejemplo, TestDox / AgileDox crea documentación simple a partir de los nombres de métodos de las clases de prueba JUnit o Pickels genera documentación basada en archivos de características escritos en Gherkin.
Los marcos como MSpec ayudan a escribir pruebas que son más MSpec leer y además proporcionan resultados legibles. Este tipo de herramientas BDD se centra en resultados legibles por humanos, lo que permite la participación de personas que no son desarrolladores después de que los desarrolladores hicieron su trabajo.
- Marcos de prueba de escenarios
Para involucrar a las partes interesadas antes en el ciclo de desarrollo , se crearon nuevas herramientas que se centran más en la entrada legible. cucumber utiliza archivos de texto plano para proporcionar entradas legibles por humanos para pruebas automatizadas. Los archivos de texto contienen escenarios escritos en un lenguaje especialmente estructurado basado en la estructura dada cuándo y cuándo. Estos marcos son excelentes herramientas que apoyan la definición colaborativa de criterios de aceptación.
- Marcos de Pruebas de Aceptación
Paralelamente a la idea de la BDD, se ha desarrollado otro tipo de herramientas, donde FIT fue uno de los primeros representantes. Este marco para pruebas integradas permite especificar ejemplos dentro de tablas que están incrustadas en una documentación relacionada con los ejemplos. Para escribir estos documentos, no se requieren habilidades de desarrollo y pueden ser leídos y revisados fácilmente por personas no técnicas, ya que se basan exclusivamente en texto. Además, el texto se puede estructurar ya que los documentos no son archivos de texto sin formato, sino la salida de editores enriquecidos.
FitNesse permite especificar el comportamiento esperado en colaboración en base a un wiki. Como los wikis son fáciles de acceder y usar, tienen una baja entrada y una curva de aprendizaje, lo que impulsa el trabajo común de todo el equipo. Muchos defensores ágiles enfatizan que la mejor forma de colaboración es la comunicación cara a cara. Pero, si escribe lo que ha pensado y discutido, debe ser lo más rico y bien estructurado posible.
Concordion proporciona mucha flexibilidad, ya que puede describir sus requisitos en lenguaje normal utilizando párrafos, tablas y puntuación adecuada. Cualquier parte de su descripción se puede usar como entrada para sus pruebas automatizadas y para la validación de las salidas de su sistema bajo prueba. Al estar basado en HTML puede estructurar sus documentos e integrar imágenes. Simplemente, tiene la expresividad de la web para describir el comportamiento esperado.
BDD debería ayudar a construir el producto correcto
Podría implementar BDD con los tres sabores de herramientas, pero cada uno tiene sus fortalezas y debilidades. Los marcos de prueba de unidad y las herramientas xSpec utilizan perfectamente los puntos fuertes de la programación. Como son herramientas de desarrolladores para desarrolladores , son una opción perfecta si intentas obtener la parte técnica adecuada.
Cuando quiera comunicar la intención de la aplicación, probablemente esté mejor con una herramienta que está fuertemente relacionada con las herramientas que los editores utilizan para su trabajo. Si una especificación contiene solo entradas y salidas esperadas, cualquiera que la lea tendrá que reconstruir sus ideas a partir de la relación de las entradas con las salidas esperadas. Una breve descripción que explica el objetivo de una especificación en el encabezado ayuda al lector a comprender la estructura de la especificación. Los documentos basados en especificación por ejemplo podrían verse como:
Sí, SpecFlow es genial, NSpec es genial ...
FitNesse y Concordion también son geniales
Una verdadera herramienta basada en el comportamiento sería algo como pepino. Lo usamos en mi trabajo contra el código .NET. Esto nos permite escribir características que definen el comportamiento del sistema como un todo y luego podemos ejecutar las funciones y verificar que el sistema hace lo que esperamos. Todo el proceso funciona muy bien para nosotros.
Hay una implementación de .net llamada NStep que se conecta al pepino a través del protocolo de conexión, que le permite escribir definiciones de pasos en C # usando lambdas ... es bastante impresionante.
Las definiciones de los pasos se ven así:
When("^I go to the /"([^/"]*)/" (?:[Ss]creen|[Pp]age)$", (string pageName) =>
{
var screen = ParseScreen(pageName);
GoToScreen(screen);
World.Browser.Wait(1000);
});
¿No puedo usar herramientas de prueba de unidad normales? BDD es un proceso y una mentalidad y, sí, puede hacerlo con cualquier herramienta (o no, puede escribir el suyo sin una herramienta si lo desea). Sin embargo, las herramientas TDD tenían ciertas suposiciones que causan cierta fricción al tratar de hacer las cosas de una forma BDD. Por ejemplo, TDD asume que está probando una unidad arquitectónica del software; clase, modulo, servicio. Mientras que BDD asume que está especificando alguna parte funcional del sistema.
¿Debo usar SpecFlow / Cucumber para describir los componentes de nivel inferior? En primer lugar, creo que la pregunta está un poco equivocada. No tendería a describir los componentes a menos que esos componentes representen directamente el comportamiento. Todavía responderé lo que creo que es el espíritu de la pregunta.
Las herramientas orientadas a historias como Cucumber son excelentes para hablar sobre el comportamiento desde la perspectiva del cliente / usuario. Puede permitirle realizar especificaciones que sean fácilmente accesibles para los legos. Sin embargo, puede ser tedioso describir grandes cantidades o un estado complejo con esas herramientas.
Pruebas unitarias, o más herramientas de especificación orientadas al código como rSpec y Machine.Specification, pueden ser mucho más convenientes cuando se trata de configuraciones de estado grandes o complejas. Puede utilizar las diversas herramientas disponibles para los idiomas para administrar el estado. Cosas como herencia y falsificaciones / simulacros. Machine.Specification tiene algunos buenos enfoques para esto para los que piensan .NET.
Entonces, ¿debería usar Cucumber para especificar un comportamiento de nivel inferior? Solo diría si es importante tener altos niveles de visibilidad para ese comportamiento en particular. En mi proyecto actual, hemos desarrollado un componente arquitectónico para representar ciertas partes del sistema que requieren un uso intensivo de las reglas de negocios. Esos componentes se especifican con Cucumber, pero la mayoría del sistema está cubierto con NUnit.
Por cierto, SpecFlow es realmente agradable y accesible para la gente de .NET que acaba de entrar en BDD, pero eventualmente querrás pasar a la versión completa de Cucumber + nStep. El ecosistema del pepino es ENORME y útil. SpecFlow es mucho más pequeño.
Además, la sintaxis lambda ofrecida por nStep es bastante mejor que tener que decorar los métodos a SpecFlow o Cuke4Nuke.
Descargo de responsabilidad / antecedentes: hice algunos de los desarrollos originales en nStep pero estoy usando SpecFlow en mi proyecto actual. Estoy trabajando para presentar BDD aquí y necesitaba algo simple y accesible.