A couple of people have recently written asking for advice on how to start writing scenarios. In both instances, they have started by logging in, because “that’s what the users do first”.
If you’re doing BDD, may I suggest starting not with the scenario that describes the entire user journey, but instead, the scenario that describes the riskiest bits of the journey?
Assume that whichever user has access to the system is already logged in. Logging in isn’t exactly risky. It’s been done 15,000 times before.
Hard-code the data to start with. Getting data out of a database isn’t very risky either. You can code this later without affecting the scenarios, if you can get some realistic examples of data.
Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?
Those are probably the bits which will cause your project to succeed or fail. Logging in can come later, and by the time you come to code it, you’ll have some real value that people want to log in for.
I’ve found a few places recently where the word “Test” has been used in combination with the words “Behaviour Driven” (with or without the “u”). Normally this makes me wince; the whole origin of BDD was intended to separate the act of describing behaviour through examples from the act of testing! Part of my self-appointed role in the BDD community is to be the anchor at the far end of that scale – you’ll hear me say “It’s not about testing!” a lot, especially if I’m answering a question about how to use JBehave to produce some particularly complex set of tests.
This post by Elizabeth Hendrickson describes her use of a BDD framework for genuine testing. Here, Elizabeth is acting in the role of a tester, and using RSpec imaginatively to support her work. Testing is a very different discipline to the act of describing what a system should do, or what a class should and should not be responsible for, and I think this example illustrates that point nicely.
If you find yourself struggling with BDD’s language, or wanting to know how to do something with BDD that only makes sense after the code’s already been written, separating the idea of testing from describing behaviour and responsibility may help you work out what it is you’re trying to achieve and express that to others. Testing is crucial to good software development; it may be that you’re doing something else.
Comments