Yurii Rashkovskii's Blog

Can you be more specific about “some advantages”?

Also – if you’re going to add keywords like :reason, why bother w/ specify_negatively at all? Why not just do this?:

specify "something", :ignore => "BUG" do
end

Well, advantages are usually a subjective thing. I just like the way negative tests are printed now, it looks very smooth for me both in terms of code and output.

Anyway, yes, I’ve thought already about option like :ignore or :negatively. It is a good idea. I’m already trying both specify_negatively and :negatively option in some of our projects.

BTW, I think that :ignore name isn’t proper. specify_negatively is about test that should fail, but not just ignored (whether passed or failed)

In that case, there already is support for what you want. It’s just not documented, and is therefore still unofficial. However, we use it within RSpec for our own specs. Why don’t you check it out and let me know what you think. Perhaps we’d consider making it an official feature:

specify "this should fail", :should_raise => Spec::Expectations::ExpectationNotMetError do
  ...
end

or

specify "this should fail", :should_raise => [
  Spec::Expectations::ExpectationNotMetError,
  "message" 
] do
  ...
end

or

specify "this should fail", :should_raise => [
  Spec::Expectations::ExpectationNotMetError,
  /message/
] do
  ...
end

You can specify any type of error, with or without a message, and the message can be a String for an exact match or a Regexp for a Regexp match.

David,

your example looks interesting, except one thing—simplicity (“type less”), which i suppose to be important for us, lazy programmers :) specify_negatively still looks very simple to remember and to type for me.

Anyway thank you for your disclosure of an unofficial feature.

As I think about it, I think my biggest resistance is to the name itself: specify_negatively. I’m not sure why, but that tells the wrong story to me. Since the goal is to say “this spec should fail”, what about something like “specify_failure”, or “expect_failure”? That last one seems most well aligned if you’re keeping track of bugs this way. WDYT?

specify_failure seems to be a bit different. Compare:

 
  specify_failure "should accept all spam" do
  end
 

and

 
  specify_negatively "should accept all spam" do
  end 
 

For me, second option looks better in terms of language. But I’m not a native English speaker. Anyway, if name is a biggest reason for resistance for an adoption of specify_negatively technique (and quite simplistic implementation), I’m ready to discuss it, of course.

:reason => “BUG” is a bad example. Bugs are identified by the failed tests, while tests themselves must be positive or, at least, positive-in-future (you call them “negative”). This is a “zero defects methodology”.

What about language and common sense, it’s really better to have all tests test features, not their negations. I’d rather prefer “delayed” or “planned” instead of “negative”. Anyway, the concept is interesting no matter how’d you call it.

Oleg, let me explain

:reason => “BUG” means following. You develop a code that reproduces found bug, and make it specify_negatively, so it will fail if bug is still present.

Ok then. But now, the whole spec looks like double-nagation (which is prohibited in English :). I suggest the following:

aspect “Known issues” do specify ”#1234 Spam attack” do # Try 1000 requests and check DB end end

Both ways seems to interesting to continue experimenting with.