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!
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.
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?
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?
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.