I’ve been working on BDD support in a test framework for Scala
imaginatively called ScalaTest, and I want to add support for the
notion of pending examples. I see three different “forms” of pending
in RSpec, and I’m curious to hear which ones RSpec users find most
useful. The three forms are:
1. With no block you get a PENDING (Not Yet Implemented) in the report
it “should say foo”
2. Passing a string, but no block, to pending. You get the PENDING
(get the vocal chords working) in the report.
it “should say foo” do
pending(“get the vocal chords working”)
subject.should say(“foo”)
end
3. Pass a string and a block to pending. If the pending code raises
an exception, then you get PENDING (get the vocal chords working)k
but if not, I believe the whole tests fails to let you know you need
to drop the pending stuff now that it works (I may be wrong).
it “should say foo” do
pending(“get the vocal chords working”) do
subject.should say(“foo”)
end
end
Which of these forms do you find the most useful in practice, and are
there any that you think would be better left out?
I’ve been working on BDD support in a test framework for Scala
imaginatively called ScalaTest, and I want to add support for the
Very cool!
notion of pending examples. I see three different “forms” of pending
in RSpec, and I’m curious to hear which ones RSpec users find most
useful. The three forms are:
1. With no block you get a PENDING (Not Yet Implemented) in the report
it “should say foo”
I rarely use this, as I don’t write a lot of specs up front.
2. Passing a string, but no block, to pending. You get the PENDING
(get the vocal chords working) in the report.
it “should say foo” do
pending(“get the vocal chords working”)
subject.should say(“foo”)
end
I find myself using #2 the most. I use it when I want to reduce noise
diring
a refactoring that breaks a lot.
I sometimes use this when I’m not sure why the example is failing, but
don’t
want to look into it right now.
Which of these forms do you find the most useful in practice, and are
there any that you think would be better left out?
but if not, I believe the whole tests fails to let you know you need
to drop the pending stuff now that it works (I may be wrong).
it “should say foo” do
pending(“get the vocal chords working”) do
subject.should say(“foo”)
end
end
Which of these forms do you find the most useful in practice, and are
there any that you think would be better left out?
Don’t forget xit(), either, which doesn’t run a group of tests.
pending with a string is what I use most often, but pending with a
block (with or without a string) is immensely helpful when refactoring.
Thanks for your replies. I have a couple quick follow up questions.
On Thu, Mar 12, 2009 at 3:05 PM, aslak hellesoy [email protected] wrote:
notion of pending examples. I see three different “forms” of pending
in RSpec, and I’m curious to hear which ones RSpec users find most
useful. The three forms are:
1. With no block you get a PENDING (Not Yet Implemented) in the report
it “should say foo”
I rarely use this, as I don’t write a lot of specs up front.
OK. One use case I see for pending is writing the spec text before the
example code. No one yet has said they actually do this in practice.
Anyone care to admit this feature is important to them?
You know there’s already an “ignore” feature in ScalaTest’s Spec,
which I think is probably like xit in RSpec. You just select “it” and
change it to “ignore”. That means temporarily ignore this test, which
most likely broke because I’m doing refactoring. What’s missing is
that there’s no way with ignore to specify a string like you can with
pending #2. What do you usually put in that string?
I sometimes use this when I’m not sure why the example is failing, but don’t
want to look into it right now.
I guess I’m curious:
How important is it to you to be able to just “strike out” the
lines of code within an example that are failing (as you can with
RSpec’s #3 pending form), versus just “striking out” the entire
example as you can with ignore in ScalaTest.
How important is it to you to be able to add a string message to
your stricken code, as you can with either #2 or #3 in RSpec? How does
that string help you?
How important is it to you to be able to just “strike out” the
lines of code within an example that are failing (as you can with
RSpec’s #3 pending form), versus just “striking out” the entire
example as you can with ignore in ScalaTest.
I don’t personally ever strike out parts of an example - all or nothing
How important is it to you to be able to add a string message to
your stricken code, as you can with either #2 or #3 in RSpec? How does
that string help you?
1. With no block you get a PENDING (Not Yet Implemented) in the report
it “should say foo”
I rarely use this, as I don’t write a lot of specs up front.
OK. One use case I see for pending is writing the spec text before the
example code. No one yet has said they actually do this in practice.
Anyone care to admit this feature is important to them?
Sure, I’ll use it occasionally: I’ll add three or four cases and then go
to work.
It probably wouldn’t be a big deal if rspec didn’t have it, though, as I
never leave them before completing them.
You know there’s already an “ignore” feature in ScalaTest’s Spec,
which I think is probably like xit in RSpec. You just select “it” and
change it to “ignore”. That means temporarily ignore this test, which
most likely broke because I’m doing refactoring. What’s missing is
that there’s no way with ignore to specify a string like you can with
pending #2. What do you usually put in that string?
it “should do such and such” do
pending ‘This is a bug which I can’t currently figure out. Revisit
once feature X is done’
…
end
I sometimes use this when I’m not sure why the example is failing, but don’t
want to look into it right now.
I guess I’m curious:
How important is it to you to be able to just “strike out” the
lines of code within an example that are failing (as you can with
RSpec’s #3 pending form), versus just “striking out” the entire
example as you can with ignore in ScalaTest.
Striking out the entire example is what’s important - not a subset of
the spec.
How important is it to you to be able to add a string message to
your stricken code, as you can with either #2 or #3 in RSpec? How does
that string help you?
It makes it clear why I made it pending in the first place, and went
ahead and committed it anyway without finishing it.
That’s my workflow - others may be different, especially with the advent
of rbehave / story runner / cucumber.
Thanks for your replies. I think I’ve settled on just using two of
RSpec’s pending forms in ScalaTest. If you want to write out a few
spec texts before writing the examples, you’d put pending in parens
where you’d normally put the block of example code:
it(“should do something”) (pending)
it(“should do something else”) (pending)
If something breaks during refactoring, you can either ignore the
whole thing by changing it to ignore like this (which already is
supported):
ignore(“should do something”) {
// …
}
Or by puttting a pending with a string inside the example block of code:
it(“should do something”) {
// …
pending(“this won’t start working again until I…”)
// …
}
But I’ll leave out the pending form that takes a block.
I appreciate the feedback.
Thanks.
Bill
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.