its
isn't core to RSpec. One the of the focuses of RSpec is on the documentation aspects of tests. Unfortunately, its
often leads to documentation output that is essentially lies. Consider this spec:
User = Struct.new(:name, :email)
describe User do
subject { User.new("bob") }
its(:name) { should == "bob" }
end
$ bin/rspec user_spec.rb --format doc
User
name
should == "bob"
Finished in 0.00085 seconds
1 example, 0 failures
Randomized with seed 25153
It's not a true behavior of User#name
that it always equals "bob". its
generally leads to output that is true in a specific case, but false in the general case, and doesn't help understanding when reading the documentation output.
Those who like its
tend to really like it and want to continue to evolve it to do more and more powerful and terse things, such as having it support arguments. We're uncomfortable with making its
more and more meta (it's already meta enough!). We were planning on moving its
into an external gem when we removed it from rspec-core, and @dnagir has already done that:
Recently, we've also found some cases where there was some surprising, non-intuitive behavior with example groups that use subject
and its
:
rspec/rspec-core#768 (comment)
I think its
gains you terseness at the expense of clarity, and in my judgement, it's a poor tradeoff.
I also feel like rspec-given is a better direction to go with one-liners. If you like one-liners, rspec-given encourages Given/When/Then one-liners, with no example docstrings at all. It's more of a unified vision for this kind of thing than the its
method in rspec-core.
Finally, you can read @dchelimsky's thoughts on its
from a while ago.
Excellent writeup. 👍 Is there a migration guide somewhere? (migrating some rspec 2 tests to 3.x right now).