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.

RSpec isn't aiming to be used as plain English; that's more of a Cucumber thing. I appreciate RSpec for that.

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 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.