Hi folks,
Wondering what the best (that is, neatest and most supported) way to
conditionally turn off some specs depending on the runtime platform.
Background: some of my specs call out to some third-party tools that
may or may not be installed on the system. I’d like to check for the
presence of those tools and gracefully skip those specs rather than
just bombing out.
The following trick, calling “pending” from inside the before block,
effectively does what I want. But I’m wondering if I can count on this
behaviour going forward? What do you think?
describe ‘Something’ do
before do
if required_tools_not_installed
pending ‘not running on this platform’
end
end
it 'should do something' do
1.should == 1
end
end
Cheers,
Wincent
On Sep 25, 2008, at 9:50 pm, Wincent C. wrote:
it ‘should do something’ do
1.should == 1
end
end
Hi Wincent
How about wrapping it this way instead…
describe ‘Something’ do
if required_tools_installed
it ‘should do something’ do
1.should == 1
end
end
end
That will make them invisible (for better or worse).
How come you need this? Is what you really need to spec that the tool
itself degrades gracefully? eg
describe ‘Something’ do
if required_tools_installed
it ‘should do something’ do
1.should == 1
end
else
it ‘should inform the user the tool is missing’
end
end
Ashley
–
http://www.patchspace.co.uk/
On Sep 25, 2008, at 4:50 PM, Wincent C. wrote:
The following trick, calling “pending” from inside the before block,
it ‘should do something’ do
1.should == 1
end
end
Cheers,
Wincent
Just wrap your platform dependent specs in an “if”. I used to have
specs which would fail on ruby 1.8.5, and so I did something like the
following:
unless on_ruby_1_8_5?
it “should…” { }
end
Scott
El 26/9/2008, a las 13:30, Ashley M.
[email protected]
escribió:
end
describe ‘Something’ do
if required_tools_installed
it ‘should do something’ do
1.should == 1
end
end
end
That will make them invisible (for better or worse).
Yeah, that’s another way of doing it.
end
end
No, it’s actually a case of having a bunch of Java junk installed on
my local system which I can use to do extended testing of things like
feed validity on this machine, while on the server I don’t have (and
can’t install) the Java stuff so would like to skip those specs.
Cheers,
Wincent
On Thu, Sep 25, 2008 at 3:50 PM, Wincent C. [email protected]
wrote:
The following trick, calling “pending” from inside the before block,
effectively does what I want. But I’m wondering if I can count on this
behaviour going forward? What do you think?
Pending is not going anywhere.
Cheers,
David
El 26/9/2008, a las 14:59, “David C.” [email protected]
escribió:
On Thu, Sep 25, 2008 at 3:50 PM, Wincent C. [email protected]
wrote:
The following trick, calling “pending” from inside the before block,
effectively does what I want. But I’m wondering if I can count on
this
behaviour going forward? What do you think?
Pending is not going anywhere.
I didn’t think so… I was mostly concerned about the fact that I am
(ab)using it by calling it from inside the “before” block…
Cheers,
Wincent
On Fri, Sep 26, 2008 at 8:42 AM, Wincent C. [email protected]
wrote:
I didn’t think so… I was mostly concerned about the fact that I am
(ab)using it by calling it from inside the “before” block…
That doesn’t strike me as abuse 
Though - we have talked about adding support for arbitrary tags which
could be exposed to the runner and let you do arbitrary things (like
only running examples with or without certain tags). Maybe, someday
…
El 26/9/2008, a las 16:16, “David C.” [email protected]
escribió:
this
behaviour going forward? What do you think?
Pending is not going anywhere.
I didn’t think so… I was mostly concerned about the fact that I am
(ab)using it by calling it from inside the “before” block…
That doesn’t strike me as abuse
Glad to hear you think so!
The truth is, sticking the check in the “before” block “feels” right,
at least to me, because asking “can I run this example?” is something
that I (obviously) want to do before running each example. Bonus is
that the examples in question print out the pending message rather
than just disappearing into the nether.
In contrast, nesting all the affected examples inside a large “if”
feels much nastier.
Cheers,
Wincent
On Fri, Sep 26, 2008 at 5:13 AM, Wincent C. [email protected]
wrote:
No, it’s actually a case of having a bunch of Java junk installed on my
local system which I can use to do extended testing of things like feed
validity on this machine, while on the server I don’t have (and can’t
install) the Java stuff so would like to skip those specs.
It seems to me that if the tests are useful to run on your local system,
they would be equally useful to run on the server. Otherwise, why run
the
server tests at all? They are obviously not going to catch any errors
that
the Java code catches.
///ark
On Sep 26, 2008, at 10:31 AM, Wincent C. wrote:
block,
Glad to hear you think so!
The truth is, sticking the check in the “before” block “feels”
right, at least to me, because asking “can I run this example?” is
something that I (obviously) want to do before running each
example. Bonus is that the examples in question print out the
pending message rather than just disappearing into the nether.
In contrast, nesting all the affected examples inside a large “if”
feels much nastier.
I don’t think so. In fact, I’ve seen it in spec’s codebase itself,
where they skipped some examples for jruby, but not for MRI.
Here is another variation on the technique:
pend_if_on_ruby_1_8_5 do
… your examples here …
end
def pend_if_on_ruby_1_8_5
if RUBY_VERSION == “1.8.5”
xit “Skipping examples because on 1.8.5”
else
yield
end
end
Scott