This project is read-only.

BDD StoryQ for every test?

Jul 8, 2010 at 7:25 AM
Edited Jul 8, 2010 at 9:58 AM

Do you use StoryQ for any kind of tests like unit, programmer and integration tests. Or do you use the StoryQ tests only for bigger pictures scenarios or when you want to have customer in the loop?

Jul 8, 2010 at 9:49 AM

Hello Robert,I just came across StoryQ yesterday so everything written here is only opinion.

I'll be using StoryQ only for bigger picture scenarios. They say BDD is TDD done properly; the outer loop of user acceptance tests driving an inner loop of unit (and perhaps integration) tests - you may have known that already sorry if that was patronising. StoryQ, for me, facilitates the outer loop of user acceptance tests very nicely.

So I'll have a feature to develop decribed by a user story. I'd code features acceptance test using StoryQ and get it failing. I'd then write a failing unit test (as per normal) and code to pass the unit test then refactor. I'd then rerun the acceptance test, ok still fails.... I haven't finished the feature yet. I'll write another failing unit test and write the code to pass, refactor. Rerun the acceptance test, it passes... ok my feature is now complete and I can move on to the next feature. StoryQ is on the outer loop.

A really good book on this is the RSpec book, Pragmatic Bookshelf, it's covers BDD using Ruby, it's very good book on BDD itself.

Hope that helps; what are your thoughts on the matter?

Jul 8, 2010 at 10:09 AM

Thx for your nice answer. It helped to get a more complete picture.

For myself I believe I will try to do every kind of test with StoryQ. For Unit-Tests I am starting to use less complete descriptions and I skip the scenario (WithScenario) and the benefit (InOrderTo) and I wish that would be supported better by the framework.

To your workflow: StoryQ has a pending state for stories that are not implemented (throw a NotImplementedException). So you don't need your Stories (Specs) to fail. I believe that is great feature! It allows you to spec many stories and give your customer, yourself a sense of achievement and a big picture how much work needs to get done.

Jul 8, 2010 at 11:16 AM

Hello again Robert, as you can tell I have some spart time today!   :)

There is another good book that covers proper TDD, it's for Java.   (

It's an interesting idea using StoryQ for unit tests as well. It's a thought that never crossed my mind. It could work, not sure, as I'm new to StoryQ but not the idea of BDD. It's an interesting twist because it's like saying the developer, in order to complete a feature, has requirements of their own. So the business requirement is produce the report and the developers requirement is to read the settings file, format the output, etc. There is nothing wrong with that idea; seems very logical actually.

Thinking it through....

You could end up with a lot of scenaros and perhaps the supporting code for each test could get very large. All the Givens in the scenaro would/could require a seperate method (like a setup, and there is no teardown with StoryQ that I know of) and all the Thats also would need a method, could result in a lot more code than just writing the traditional unit test.  Ok that was just thinking it through and might not be representative of real life at all, could be better approach.

How is the approach working out?

Jul 8, 2010 at 11:21 AM
The way in which StoryQ encourages step reuse, especially with parameters, could in fact save lines of code