3 Answers
3

Normally the purpose of BDD is to enable conversations, particularly between the business and the developers, so that the team can be sure they've reached a common understanding. We also like to include testers, because they can spot when we've missed scenarios.

If you're doing this on your own, grab a rubber duck and explain the behavior of your application to the duck. Give some examples of how it should work. Those will be your scenarios.

To start with, I would suggest not automating those scenarios. You can write them down if you like. Remember that the business outcomes that you shared with the duck are about the right level to phrase them in. You should now have an idea of how the app behaves, and you can run through the scenarios manually. I like to treat everything that doesn't work yet like a bug. I have sometimes started with automation, but only when I know very well how the system works, I'm familiar with the tools, and the UI is well understood. Even then I often have to rework it a bit when I've written the code.

At a lower level, tell your duck how each class is going to behave. Provide some examples. Rubber ducks are perfectly capable of understanding technical language. Now you have your unit-level BDD, aka unit tests. The red-green-refactor cycle happens here. (I don't tend to need to refactor so much any more, because I'm thinking about the responsibilities of my classes, phrasing it in business-oriented language, and it tends to fall out in quite a beautiful way anyway. But I've been doing this for a while now. It's OK if you do.)

Don't refactor it too much. We still want to get feedback on our code, because there's always things we don't know that we don't know. Perfection is your enemy here. Make it good enough, make it readable, then move on. If you need to make something perfect to make further changes, do it when you make further changes.

If you have the opportunity to get feedback on your scenarios from business stakeholders, but they're not sat with you, you can send scenarios to them as soon as you've written then, and before you automate them. You might want to send a mock-up of the UI, too, so that they can correlate words to actions. Don't get too far ahead of the coding with this. Work with the assumption that what you've already done is wrong, and you need to get feedback to find out how.

As one final hint, don't generally phrase stories from a user's point of view (scenarios, yes, but not stories). They're not user stories. It should probably read something like:

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

There's some higher level goal you're looking for, anyway. This will also help you draw out the capabilities you need. Good luck with it, and apologies for the extra-long post.

I've made a new question... "If I should write my scenarios before ...". May you take a look please? Thank you very much.
–
thomJul 8 '11 at 20:14

1

@S.Lott Good answer but one quibble: based on the usefulness of the red-green-refactor cycle, I would suggest refactoring continuously during the BDD process, right after each green test.
–
Rein HenrichsJul 8 '11 at 20:38

@Rein Henrichs: An alternative would be to note that refactoring in order to finish all the tests for one story happens as an inevitable and inescapable part of coding. Even a great design can't cover all the bases. That refactoring didn't seem worth mentioning. However, you did point it out nicely. Refactoring between stories, however, is a more serious and time-consuming operation, since the feature set evolves by the accretion of stories.
–
S.LottJul 9 '11 at 12:35

@thom: user stories should express what the user wants to be able to do, not how it will be implemented. In other words, features, stories, and scenarios are requirements and functional specifications. Don't make design decisions until you have the full picture. In this (presumably artificial) example the business needs of the user overall may indicate that a webpage may not be the most convenient solution - a desktop widget or mobile app might be better, depending on how/when they need to use it. Implementation details clutter the stories, and may lock you into a specific design too soon.
–
Steven A. LoweJul 9 '11 at 0:56