Actually, quite to the contrary, I think it's more semantic. What you probably don't know is that `Foo#bar` is the way of describing an instance method `bar` in class `Foo` and `Foo.bar` is a class method. RSpec's `describe` announces what unit of code you're writing specs for and `context` (although functionally equivalent to `describe`) is used to enumerate the different contexts in which you're going to test a method.
A typical spec looks like this:
describe Foo do
describe "#bar" do
# specs for Foo#bar ...
end
describe ".baz" do
# specs for Foo.baz ...
end
end
The reason I say that using the method names for `describe` is more semantic is because it says exactly what you're describing. Also, as a side note, RSpec is smart enough to realize that "#bar" or ".baz" are referring to methods. In the above example, a spec for `Foo#bar` would be described like this: "Foo#bar should return 42". That's the description that is printed out when the spec fails or if you use a long-form output formatter.
Personally I don't like the first example. I also don't believe it resembles cucumber at all.
It's certainly more closer to a documentation string (the ones you see in python or common lisp).
In any case given the following:
describe 'if the user is an admin' do
versus
describe '#admin?' do
Ignoring the fact that the author is ignoring BDD here, I certainly like the first one more, even if the user part is a bit redundant.
Nevertheless, what the author has done is commendable but there are few cases there that I just can't agree with. I don't see anything really wrong about them, it's just that in real life things can get complicated.
To be honest, I think both styles are good practice, but it totally depends on the context. For example, if I want to describe how the "#admin?" method is working, I'll use
describe "#admin?" do ...
but if I'm describing a different method, that does different things depending on whether the user is an admin or not, I'll do the following:
describe "#some_other_method" do
describe "if the user is an admin" do
...
So you can mix and match both styles, depending on what exactly you're describing (and it's context).
If you're looking at the OP more closely, it even says this is only recommended for "describing methods".
As an experience Ruby dev, these are pretty much all standard practices in real projects. I don't like shared examples, wince at the thought of that much complexity being hidden away in a test!
I keep shared examples to a minimum, but I do find them useful in some cases, such as when I have to test the same few attributes over and over in different contexts. But I define the shared example in the same file that uses them, and never have project-wide shared example groups.
I am (I'm a beginner), and I agree. I'm actually reading The RSpec Book right now, and though I'm not far into the RSpec docs, it seemed to suggest using this sort of documentation.
I know it may look strange in isolation bit I found it worked well to help ensure I had unit tests across each of my methods as I would list each method using the suggested style here. Also i find where I want more narrative context eg more nicely worded lines I would make describe or context which wrap around a specific method test or group of methods being tested.
Once you have lots of tests, then this style approach just takes out more of the thinking up what to write mental effort and also provides a nice clean consistent style across your whole project.
