Tiene sentido usar TDD para biblioteca/código API y BDD como pruebas de integración?

Question

Soy un novato completo de BDD y me gustaría entender dónde entra en juego en un ciclo de desarrollo. En los enfoques TDD, escribiríamos pruebas unitarias comúnmente para bibliotecas o aplicaciones, nos burlaríamos de objetos y eso fue genial porque incluso podría impulsar nuestro diseño. Estas pruebas se escribirían antes del código real, lo cual es bueno.

Entiendo que BDD tiene más que ver con las pruebas de especificación/escenario y puedo ver que es una opción perfecta para probar un requisito comercial en comparación con el código real. Pero, ¿cuál es la mejor práctica para escribir estas pruebas? ¿Seguimos escribiendo pruebas individuales (como en TDD) burlándose de las dependencias y escribiendo pruebas unitarias por cada cosa que podría salir mal? ¿Entonces escribe nuestras pruebas bdd? ¿Escribimos las pruebas bdd primero? ¿Escribimos solo pruebas bdd incluso contra componentes individuales?

Uso .NET y generalmente escribo aplicaciones asp.net mvc, pero esto es más una cuestión de teoría e independiente del lenguaje de programación subyacente.

Muchas gracias.

Answer 1

No sé de la manera correcta, pero esta es mi experiencia. Después de analizar el documento de especificación, trato de extraer tantas "historias" diferentes y describirlas usando archivos de historias BDD. Como ya sabe, cada oración debe comenzar con cualquiera de las tres palabras clave dadas, cuando y , luego.

Después de traducir toda la especificación a las historias de prueba de BDD, escribo una clase que implementa los pasos, es decir, ejecuta cada una de las oraciones que se usan en las historias.

El siguiente paso es comenzar a escribir una implementación que será invocada por métodos que ejecutan oraciones de guiones estableciendo estado inicial (dado), transiciones de estado (cuando) y verificando el estado de destino de la aplicación (luego).

Cada vez que necesito implementar un método de clase real, uso TDD para realizar una prueba minuciosa de forma aislada.

Por supuesto, para ejecutar la prueba, parte del código que aún no está implementado puede ser burlado temporalmente.

Answer 2

Puede usarlo de manera similar a TDD, pruebas unitarias u otras. La diferencia vendrá de probar "Comportamiento empresarial". Flujo de especificaciones y características es una opción, la sintaxis de las pruebas unitarias se vería algo como esto

[Given(@"a user exists with username ""(.*)"" and password ""(.*)""")] 
public void GivenAUserExistsWithUsernameAdminAndPasswordPassword(string userName, string password) { 

} 

[Then(@"that user should be able to login using ""(.*)"" and ""(.*)""")] 
public void ThenThatUserShouldBeAbleToLoginUsingAdminAndPassword(string userName, string password) { 
     Assert.IsTrue(_authService.IsValidLogin(userName, password)); 
    } 

Answer 3

BDD es un conjunto de patrones en torno a la descripción y la construcción de modelos del comportamiento de un sistema (y, en un nivel superior, un proyecto visión) que nos puede ayudar a tener conversaciones sobre ese comportamiento, para varios niveles de granularidad.

Usamos patrones de conversación como "Dado un contexto, cuando ocurre este evento, debería ocurrir este resultado", y fomentamos preguntas como, "¿Debería? ¿Siempre? ¿Hay algún otro contexto que nos falta?"

Podemos hacerlo en un nivel de unidad, un nivel de escenario o incluso en el espacio de análisis.

Tiendo a trabajar desde el nivel más alto hacia adentro. Here's an article I wrote que describe cómo se ve, justo desde la visión del proyecto hasta las pruebas unitarias.

El primer bit del código que escribo serán los escenarios.Here are some scenarios escrito sin marcos BDD, simplemente antiguo NUnit, que muestra cómo se puede leer en inglés con el idioma del dominio, etc.

Luego empiezo con la interfaz de usuario. Esto podría ser una GUI, página web o una interfaz para que otro sistema use mi sistema. Una vez hecho esto, puedo obtener comentarios sobre si a mis usuarios les gusta. Frecuentemente codifico datos, etc., solo para poder obtener esos comentarios.

Una vez que sé aproximadamente qué aspecto tendrá mi GUI, puedo comenzar a crear el comportamiento detrás de ella. Normalmente comienzo con el comportamiento del controlador. Escribiré ejemplos a nivel de clase que describan el comportamiento y las responsabilidades de la clase. Uso burlas en lugar de clases colaboradoras que todavía no he escrito. Esto es el equivalente de TDD, pero en lugar de escribir pruebas que anclan el código para que nadie lo rompa, estoy escribiendo ejemplos de cómo puedes usar mi código, que muestra cómo se comporta y por qué es valioso para que puedas cambiar es seguro ¡También uso Given/When/Then para esto! Pero tiendo a usar un lenguaje más técnico y no me preocupo porque sea legible en inglés. Frecuentemente mi Given/When/Then solo está en comentarios. Here's an example of class behaviour desde la misma base de código que los escenarios, para que pueda ver cuál es la diferencia.

Espero que esto ayude, y ¡buena suerte con el BDD!