Optimal workflow for doing bdd with rspec specs and story frameworks

Rails
1

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.

2

Quoting Marcelo de Moraes S. [email protected]:

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

3

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?

On Sun, Jun 15, 2008 at 10:52 PM, Jeffrey L. Taylor
[email protected]

4

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

http://aaswathaman.blogspot.com/

5

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

6

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.

On Mon, Jun 16, 2008 at 5:46 AM, Ayyanar Aswathaman <

7

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?

On Tue, Jun 17, 2008 at 12:19 AM, Ayyanar Aswathaman <

8

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 S. [email protected]:

9

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.

On Tue, Jun 17, 2008 at 9:04 AM, Jeffrey L. Taylor
[email protected]

10

On Wed, Jun 18, 2008 at 9:06 AM, Jeffrey L. Taylor
[email protected] wrote:

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.

You can run a single example with rspec as well:

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

HTH,
David

11

Quoting Marcelo de Moraes S. [email protected]:

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