design - Cómo escribir historias/escenarios en BDD(Diseño impulsado por el comportamiento)

user-stories

Question

Estoy a punto de utilizar BDD (Behavior Driven Design) por primera vez y estoy tratando de acostumbrarme a esta forma diferente de abordar un problema.

¿Puedes dar algunas historias / escenarios para los que escribirías, digamos una aplicación de inicio de sesión simple usando BDD?

Por ejemplo, por lo que he leído, parece que es bueno:

Cuando un usuario ingresa una ID de usuario / contraseña inválida, entonces muestra un mensaje de error.

Opuesto a:

Valide la identificación y la contraseña buscando un registro coincidente en la base de datos.

Answer 1

Dan North tiene algunos consejos excelentes para escribir historias. "Dan North- ¿Qué hay en una historia?"

También echaré un vistazo a parte del trabajo que se está haciendo en torno a Cucumber, ya que han dedicado mucho tiempo a pensar sobre cómo escribir estas historias de una manera comprensible y ejecutable.

Answer 2

El artículo de Dan North que _Kevin mencionó es genial.

Sin embargo, recuerde que hay "historias de usuarios", que en realidad deberían escribirse o, al menos, recopilarse del cliente / usuarios. Estas son más historias tipo "Como, quiero, así que".

Luego, existen criterios de aceptación que identifican cómo y cuándo se cumplirá la historia del usuario. Eso es como lo que has escrito en tu publicación: "Cuando x, debería y".

Hay mucha coincidencia aquí con lo que llamo "historias del sistema" en mi sistema de gestión de proyectos y "especificaciones" en mis pruebas que especifican el comportamiento del que el usuario puede no estar enterado, pero describen la interacción entre sus clases. Historia del sistema: "Cuando LoginHandler recibe un nombre de usuario y contraseña, debe validar los datos con un LoginValidator". Especificación:

[TestFixture]
public class When_the_login_handler_is_given_a_login_and_password
{
   constant string login = "jdoe";
   constant string password = "password";
   static LoginValidator loginValidator;

   context c = () => loginValidator = an<ILoginValidator>;

   because b = () => sut.Validate(login, password);

   it should_validate_the_data_with_a_LoginValidator =
      () => loginValidator.was_told_to(x => x.DoValidation(login, password));
}

Sin importar la sintaxis de la prueba, puede ver que el texto de la especificación en sí está incluido en el nombre de la clase de prueba y el método. Además, la prueba / especificación en realidad está probando el comportamiento de las clases. Cuando las pruebas como esta pasan por simples historias de usuarios, se cumplen los criterios de aceptación.

Answer 3

Encontré una excelente charla aquí https://skillsmatter.com/skillscasts/2446-bdd-as-its-meant-to-be-done (precaución, necesitas crear una cuenta para ver el video)