On 30/04/2009, at 7:59 AM, Kero van Gelder wrote:
So basically, I want to do something like this:
examples = load_examples_without_running
examples.each {|example| puts example.description}
[snip]
I'm working into a big corporate in Australia, and they are demanding
traceability of tests back to requirements. I'm already using
Mingle to
manage story cards, and I'm hoping to let the testers build in the
traceability via code. So I've got a Mixin to the examples so that I
can declare the id of the story that the test maps to. It looks
something like this:
describe FunctionalArea do
it "automates some acceptance test declared on a story" do
traces_to_story 35
# test implementation
end
end
I would have expected Cucumber to map stories to scenarios/examples
by having them in the same file (and a @tag if someone insists that
a number referrring an external doc is better for tracability).
I would have expected RSpec to cover a lower level that is of no
interest to the person wanting traceability, as that person can not
judge whether the code works anyway (YMMV). Besides, a spec can
apply to more than one requirement; or to no particular requirement
at all.
I'm expecting this from regulations that deal with medical devices.
Validation has to happen on story level; risk mitigation may apply
to lower levels, though. Our department is working on several projects
that'll result in medical devices and we are learning how regulations,
audits and things work for real.
So I'd like to hear why you are trying to do what you do.
Sure.
There can be other requirements for other reasons. What traceability
are you looking for in these tests? Why do you look at the RSpec
level?
I don't necessarily disagree with what you are saying, but the project
was going long before cucumber existed, and we already had a heavy
investment in tests using rspec. It's a data warehousing project, so
there's little or no UI to speak of. We built a DSL on top of RSpec
to allow us to manipulate data and verify results after ETL jobs run.
Most of tests set up data, run the ETL job (calling out to an external
tool) and then verify that the results look the way they're supposed to.
So to us, RSpec isn't a 'lower level'. Perhaps if the project was
starting now, I'd consider cucumber. Our investment in a DSL on RSpec
is reasonably heavy though, and is working really well for us. I'd
rather enhance that a bit further than switch frameworks for the sake
of one feature.
-- Marty
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
