How to write stories / scenarios in BDD ( Behavior Driven Design )

Question

I am about to use BDD (Behavior Driven Design) for the first time and am trying to get used to this different way of approaching a problem.

Can you give some stories / scenarios that you would write for say a simple login application using BDD?

For example, from what I have read, it seems that:

“When a user enters an invalid userid/password, then display an error message.”

Is good, as opposed to

“Validate id and password by searching for a matching record in the database.”

Answer 1

Dan North has some excellent advice on writing stories. "Dan North- What's in a Story?"

I would also take a look at some of the work being done around Cucumber as they have spent a lot of time thinking about how to write these stories in an understandable and executable way.

Answer 2

Dan North's article that _Kevin mentioned is great.

Remember, though, that there are "user stories," which should actually be written or at least collected from the client/users. These are more of the "As a , I want , so that " type stories.

Then there are acceptance criteria, which identify how and when the user story will be said to be satisfied. That is like what you have written in your post: "When x, it should y."

There is a lot of overlap here with what I call "system stories" in my project management system and "specifications" in my tests which specify behaviour that the user may not be aware of, but describe interaction between your classes. System story: "When the LoginHandler is given a login and password, it should validate the data with a LoginValidator." Specification:

[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));
}

Nevermind the testing syntax, you can see that the specification text itself is embodied in the test class name and method name. Furthermore, the test/spec is actually testing the behaviour of the classes. When tests like this pass for simple user stories, the acceptance criteria has been met.