[rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g. xit)

noreply at rubyforge.org noreply at rubyforge.org
Mon Nov 5 19:33:54 EST 2007

Feature Requests item #13454, was opened at 2007-08-28 07:51
You can respond by visiting: 

Category: runner module
Group: None
>Status: Closed
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.


>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 00:33

This was implemented a while back.


Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 16:38

+1 for BehaviourDisabledError or ExampleDisabledError


Comment By: Brian Takita (btakita)
Date: 2007-08-30 16:31

I propose raising an error (e.g. raise
BehaviourDisabledError, "Behaviour blah blah is disabled").
This has different semantic meaning and usage from pending.
Pending can be checked in, xit cannot.

Also, to clarify, xtest in an xUnit convention (by practical
usage). It naturally works because tests are methods and you
can change the method name. I meant, xit is rspec's
equivalent to xtest.
I have been in several situations where the developer is new
to rspec and experienced with xUnit expects to be able to x
out the examples.


Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 20:40

Maybe I misunderstood the goal here. My thinking is that xit is a shortcut for pending - it should work exactly like pending does, providing its own message - so that it does keep it on the radar. I agree w/ Brian's goal of being able to swiftly switch the state of each "it" by preceding it w/ an 'x', but only if it makes sure you know about it.


Comment By: Dan North (tastapod)
Date: 2007-08-28 20:28

David said: "I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing."

The problem is, it doesn't keep it on the radar. I've found literally tens of tests commented out (or x-ed out) in a codebase, which once they were re-enabled all failed because the code no longer did what it was supposed to.

The intent behind pending() is to keep them on the radar, nagging away with every build, but without actually failing the build. You can put a pending in a describe (specify) block and it should Just Work (ie. mark the whole section and any of its examples as pending). If not this is a bug.

I'd like to challenge two of the comments in the original description. Firstly pending is exactly intended to temporarily disable examples or scenarios - that's the point! Secondly, it isn't a convention from xunit, it's a convention from jbehave - the java bdd framework - that I introduced because I didn't like the binary nature of red/green (I guess I wanted yellow!). Pending behaviour is very much a BDD initiative, although it's made its way back into the xunit world (nunit has it as an Ignore attribute on a Test).

Then I brought it into rbehave because I found it so useful - and because scenarios tend to spend longer in a "pending" state than code-level examples. Then one of the rspec devs (I think it was Brian) brought it into rspec and improved it by allowing it to wrap a block.

I would strongly encourage using pending() for exactly this use case. Ideally with a message saying what needs to be done to make it work.


Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 17:06

For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).


Comment By: Ian Dees (undees)
Date: 2007-08-28 16:04

Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'


You can respond by visiting: 

More information about the rspec-devel mailing list