Optimal workflow for doing bdd with rspec specs and story frameworks

Hello list,

I’m just starting with rspec specs framework and the rspec stories framework. I got the basics already with the peepcode screecasts, but I’m still confused on how I could implement an optimal workflow: write all the stories, let them stay empty until I complete the specs and then come back to it (for the “integration” tests) ?

I would be grateful if someone could enlighten-me here!

Thanks,

Marcelo.

Quoting Marcelo de Moraes Serpa <celoserpa@gmail.com>:

Hello list,

I'm just starting with rspec specs framework and the rspec stories framework. I got the basics already with the peepcode screecasts, but I'm still confused on how I could implement an optimal workflow: write all the stories, let them stay empty until I complete the specs and then come back to it (for the "integration" tests) ?

Write one and implement it. You will learn a lot about RSpec stories, testing in general, implementing your app and testing your app along the way. Then pick the next story and do it. All the arguments against Big Design Up Front (BDUF) apply also to Big Testing Up Front.

Jeffrey

Hi Jeffrey, thanks for the reply.

Write one and implement it. You will learn a lot about RSpec stories, testing

in general, implementing your app and testing your app along the way. Then

pick the next story and do it. All the arguments against Big Design Up Front

(BDUF) apply also to Big Testing Up Front.

So, you are suggesting me to start with the user stories, convert them to rSpec stories and follow from there to the more specific rSpec examples for classes?

You can read my blog. Hope this will address your need

http://aaswathaman.blogspot.com/

Thank you very much Ayyanar for sharing your experiences.

Something is not clear yet though, and that was the purpose of my post (sorry if I didn’t make this clear at the beginning), are rSpec specs and rSpec Stories mutually exclusive? In other words, if you use the story framework, do you need or have to also use the specs framework or does the story framework replace the need for the other?

Thanks,

Marcelo.

Basically, the story framework is to test the behaviour at application level and the spec framework is to test the behaviour at object level. They are mutually exclusive

You mean they are not_ mutually exclusive_ since they can be used at the same time for different purposes. I think they would be mutually exclusive if Story were a fancier way to do specs testing. Am I wrong?

Correct. You can have and probably should have stories to test application level features and spec tests for the internals. You can do both and use Test::Unit tests too. The one conflict I am aware of is that when you install RSpec "rake stats" no longer reports Test::Unit lines of code, etc., just RSpec lines of code.

Jeffrey

Quoting Marcelo de Moraes Serpa <celoserpa@gmail.com>:

Correct. You can have and probably should have stories to test application

level features and spec tests for the internals. You can do both and use

Test::Unit tests too. The one conflict I am aware of is that when you install

RSpec “rake stats” no longer reports Test::Unit lines of code, etc., just

RSpec lines of code.

Right. But Test::Unit and rSpec specs tests in the same application is not really necessary nor wanted as, afaik, rSpec specs are meant to be a “better” Test::Unit (or, a better way to do unit testing). So we could say that rSpec spec fw and Test::Unit are mutually exclusive.

Quoting Marcelo de Moraes Serpa <celoserpa@gmail.com>:

> > Correct. You can have and probably should have stories to test application > level features and spec tests for the internals. You can do both and use > Test::Unit tests too. The one conflict I am aware of is that when you > install > RSpec "rake stats" no longer reports Test::Unit lines of code, etc., just > RSpec lines of code. >

Right. But Test::Unit and rSpec specs tests in the same application is not really necessary nor wanted as, afaik, rSpec specs are meant to be a "better" Test::Unit (or, a better way to do unit testing). So we could say that rSpec spec fw and Test::Unit are mutually exclusive.

As they say, opinions vary. I was initially enthusiastic about RSpec. I understand the reasons for trying a more non-tech readable approach. Test::Unit has one very big advantage for me over RSpec specs, debugging. Both are fine for testing and approximately equivalent. However once a problem is found it speeds up debugging to be able to run just the test that fails. Not the whole test section (rake spec:model or rake test:units) and not the whole test file, e.g. "ruby spec/models/task_spec.rb". But the single test/function, "ruby test/units/task_test.rb -n test_validate". So I have a mixture of Test::Unit and RSpec spec and stories. Works for me.

They are not mutually exclusive which would say that using one prevents using the other. You may choose to use just one or the other, but it is your choice, not something enforced or required by either package.

Jeffrey

You can run a single example with rspec as well:

$ruby spec/models/task_test.rb -e "should be valid"

HTH, David