BDD : a change in thinking
For everyone doing TDD (test first … test driven design) bdd is not going to sound like a lot of new stuff. BDD, at its core represents a change in thinking. It drives us down the path of writing out “specifications” so that its readable to everyone involoved in the software project. It steers developers into thinking about the behaviour in a given context, and what the “user experience” is going to be like.
It brings programmers close to the business…. that’s important enough to say it again. it brings programmers close to the business.
Additionally, BDD trys to get the words changed so that we stop communicating in terms of testing. We start talking about the behaviour of a system. Its worth mentioning, there’s a couple flavours in the BDD world. The Dan North “Given , When , Then” and then there’s Scott Bellware’s “Context specification” and of course mine (pretty much context specification based on sceanrios - each scenario is an If).
Using an example of a Login specification, let check each one.
Dans style : Given incorrect credentials when the user logs in then the user should be shown a failed to login message.
Scotts’s style: When the user logs in in [in the context of having incorrect details] then the user should be shown a failed login message
Mine: If the login credentials are incorrect when the user logs in, then the user should be shown a failed login message.
How this actually looks in code depends on the underlying framework used. For me, I’ve written up my own basic one, which relys on a few simple classes (I’ll post them at a later date)
// This is quick look at the layout of the test.
// The implemenation is left out for simplicity
{
[Story]
public abstract class when_the_user_logs_in: Story_for<ILoginController> {}
// This is a scenario
public class if_the_credentials_supplied_are_incorrect : when_the_user_logs_in{}
// This is another scenario
public class if_the_credentials_supplied_are_correct :when_the_user_logs_in{}
}
