As an experiment in playing nice with others, we’ve added the ability
in rspec’s trunk to do this:
class ThingExamples < Spec::ExampleGroup
def should_do_stuff
…
end
end
This is how rspec 0.1 worked, and for people already comfortable with
the classes/methods approach of Test::Unit, it is a more comfortable
entry point to rspec.
For others, however, it has created a problem: you can’t write helper
methods that start with should_ because rspec treats them as examples.
Quick show of hands, please:
+1 (with comments please) for keeping the ability to write examples
using should_
-1 (with comments please) for bagging it because you think you should
be able to write helper methods that start with should_.
ps - In the interest of full disclosure, this is not going to be a
majority vote. My interest is in making rspec more accessible to
people who are likely not on this list and whose voices will not be
heard. I’m just looking to take a pulse from a wider group than the
few that have commented on the ticket.
pps - One suggestion that came up was to make this a configuration
option. I don’t love that because it makes rspec more complicated, but
it’s a possibility.
+1 for keeping should prefix given the number of people who write helper
methods starting with “should” (at last count, one person) versus the
number
of people who find it useful starting test methods with the word
“should” in
xunit testing frameworks (nearly everyone I know). Obviously my world is
skewed because I am part of the problem, getting people to value
“should” in
the first place.
I think supporting should is more in the spirit of playing nice with
others
(junit and test::unit folks) than not.
+1 (with comments please) for keeping the ability to write examples
using should_
-1 (with comments please) for bagging it because you think you should
be able to write helper methods that start with should_.
-1. I don’t want to encourage a third style for examples (#test_* and
RSpec #it is enough). It doesn’t bring anything new to the table,
especially
when #it can be used inside TestCase classes.
+1 (with comments please) for keeping the ability to write examples
using should_
-1 (with comments please) for bagging it because you think you should
be able to write helper methods that start with should_.
-1. I don’t want to encourage a third style for examples (#test_* and
RSpec #it is enough). It doesn’t bring anything new to the table,
Your -1 noted, however I disagree with the rationale. I think it does bring something new to the table. If you are one who prefers
classes/methods, you’d be stuck with this:
class SomeExamples << Test::Unit::TestCase::ExampleGroup
def test_foo
…
end
end
While this might be a useful transition from as T::U suite (just add
::ExampleGroup to the base class name), it feels like a transition
point, not and end. We want to encourage “should” over “test”.
especially
when #it can be used inside TestCase classes.
#it doesn’t really speak well inside a class definition:
class SomeExamples << Test::Unit::TestCase::ExampleGroup
it “foo” do
…
end
end
-1
I, as a new rspec user, did not find the switch between test_ and it
“blah” do to be even a small challenge compared to other things I had
to convert and learn. I only feel like it would be one more thing to
keep up with that would cause problems. I can certainly see someone
writing a helper method with should_ and saying “what the heck is
going on” because they didn’t fully read all the documentation. It
was plenty easy in my conversion to say “oh ok, find and replace test_
and put it “should” in place of that”. I would have certainly been
frustrated to find a hidden “feature” causing problems that I didn’t
understand.
Keeping in mind my original n00b perspective, I feel like if in my
first impression I had the option of turning on a baby-step feature
that I might have either, A - not known about it because I didn’t see
it in my first tutorial, or, B - skipped it feeling that I could
handle making that transition into the “accepted” way.
I can see how some people might find use for it, but I believe overall
the complexity would cause more confusion than it would prevent.
-1*
I upgraded a Rails project from rspec 0.9 to 1.1.2 – and this change
caused
me some pain. Luckily, I figured it out and confirmed it here on the
list
before things got too bad.
That said, I have to admit that I’m not super-pleased about my helper
methods that start with should_ – they probably should be rewritten in
some
other way. Perhaps as custom matchers. So maybe I will abstain from
this
vote after all.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
