We seem to be hitting some undesirable behavior with should_not in
combination with matchers that accept collections. Let me use the "include"
matcher for example (a co-worker reported similar problems using "be_any" so
I don't believe this is limited to "include"). The RDoc states:
Passes if actual includes expected. This works for collections and Strings.
You can also pass in multiple args and it will only pass if all args are
found in collection.
Examples
[1,2,3].should include(3)
[1,2,3].should include(2,3) #would pass
[1,2,3].should include(2,3,4) #would fail
[1,2,3].should_not include(4)
"spread".should include("read")
"spread".should_not include("red")
The RDoc doesn't give any examples of using a "should_not" along with
multiple args being passed to "include", but since I couldn't find any
documentation on why it would not work I assume that it should work. Here is
a list of tests I came up with to find out what works and what doesn't.
Note: All of these tests SHOULD fail; the problem is with the tests that do
NOT fail.
it "does properly fail on a collection when using \"should\" with
multiple args" do
[1,2,3].should include(2,3,4)
end
it "does NOT properly fail on a collection when using \"should_not\"
with multiple args when at least one value in the expected args is in the
actual collection" do
[1,2,3].should_not include(3,4,5)
end
it "does properly fail on a collection when using \"should_not\" with
multiple args when all of the values in the expected args are in the actual
collection" do
[1,2,3].should_not include(1,2,3)
end
it "does properly fail on a collection when using \"should_not\" with
multiple args when all of the values in the expected args are in the actual
collection and when the expected args don't cover all of the values in the
actual collection" do
[1,2,3].should_not include(1,2)
end
it "does properly fail on a collection when using \"should_not\" with a
single arg" do
[1,2,3].should_not include(3)
end
it "does properly fail on a string when using \"should_not\" with
multiple args when all of the values in the expected args are in the actual
string" do
"abc".should_not include("a", "b", "c")
end
it "does NOT properly fail when using \"should_not\" with multiple args
when at least one of the values in the expected args is in the actual
string" do
"abc".should_not include("a", "b", "e")
end
it "does properly fail on a string when using \"should_not\" with
multiple args when all of the values in the expected args are in the actual
collection and when the expected args don't cover all of the values in the
actual string" do
"abc".should_not include("a","b")
end
it "does properly fail on a string when using \"should_not\" with a
single arg" do
"abc".should_not include("a")
end
We are using the following rspec gems:
Rspec-1.2.9
Rspec-rails-1.2.7.1
So I think one of two things needs to happen here dependent on whether this
is desired behavior or not.
1. If this is desired behavior then an exception really should be raised if
you try to use "should_not" in combination with passing a collection to a
matcher. At the very least there needs to be some documentation to inform
RSpec users that tests will not always fail as they might expect when using
"should_not" in combination with a matcher that accepts multiple args.
2. If this is not desired behavior then of course we need a fix.
I apologize if this has been brought up previously; I did as much searching
on this issue as possible.
Thanks in advance!
Ben Fyvie
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
