I'm starting with BDD and this is my story:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

I have some doubts ...

Should I write my scenarios before coding anything or should I first write a scenario and then write code, write a scenario again and then write code, and so on ... ?

If I should write my scenarios before, can my steps be approved and production code still does not get done?

When should I do refactoring on my code? After the feature is done or after each scenario implementation?

  • "can my steps be approved and production code still does not get done?" What does this mean? Please explain.
    – S.Lott
    Jul 8, 2011 at 20:24

3 Answers 3


From the story, I infer that you're coding on your own.

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.

  • 1
    The 'rubber duck' part is great. I thought I was the only one who'd think of that!
    – NoChance
    Mar 19, 2012 at 8:24

Should I write my scenarios before coding anything or should I first write a scenario and then write code, write a scenario again and then write code, and so on ... ?

Both will work. Pick one.

It doesn't matter much.

The more scenarios you have, the more design you can do up front.

The more scenarios you have, the longer it takes to get something done.

When should I do refactoring on my code? After the feature is done or after each scenario implementation?

No. You refactor when it becomes difficult to design the next scenario.

  • I've made a new question... "If I should write my scenarios before ...". May you take a look please? Thank you very much.
    – thom
    Jul 8, 2011 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. Jul 8, 2011 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.Lott
    Jul 9, 2011 at 12:35

Use descriptive verbs

Feature: CONVERT Months and days to days

Don't make design decisions in stories ["I need a webpage" is a design decision]

As a date conversion fan
I want to convert days and months into days

Use business-value goals in stories

So that [some business reason]

Write as many features and stories as you can before starting to code; stories inform each other, influence the features, and inform the design.

Refactor after each story. Red-Green-Refactor.

  • +1, Good answer. But isn't the "BDD way" to refactor as part of the inner, unit-test cycle rather than the outer, acceptance-test cycle?
    – pdr
    Jul 8, 2011 at 22:07
  • @pdr: that's what I meant, refactor after each story. BDD/TDD tests scale from unit to acceptance, there is only one cycle (in my mind) ;-) Jul 8, 2011 at 22:52
  • Why "I need a webpage" is a design decision? Thanks!
    – thom
    Jul 9, 2011 at 0:22
  • @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. Jul 9, 2011 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.