It does. Especially considering the fact that RSpec itself was created as a joke solution to the "I wish my tests were more human readable" meme several years ago. Hopefully that sheds some light on why some of us might be hyper-sensitive about it.
I created RSpec (in early 2005) to draw people's attention away from the word "test" because it was a huge hangup while I was teaching TDD. I kept hearing "You can't test something that doesn't exist, therefore your entire idea is bunk." I wanted to introduce TDD to people without ever using the word "test", and then switch them to using xUnit instead.
Not a joke, but I guess you could reasonably describe RSpec as a tool for performing a good old fashioned bait and switch. In a classroom. (I never intended for it to be used outside of a classroom setting.)
Around the time I was looking for ways to "teach TDD without using the word", Aslak Hellesøy introduced me to Dan North's ideas of Behaviour Driven Development. That's where the word "should" came from. I don't know if it was actually Aslak or Dan (or possibly even Liz Keogh) that first used the word "should", but that wasn't my idea.
Also, I'll point out that mixing #should onto Object wasn't my fault. The original syntax looked very close to the expect().to() syntax of today. It was actually assert(foo).does_equal(bar) at one point, and this was the syntax I was most fond of. I tried dozens of different combinations. "#should" was one of many, and I didn't like it. It got released this way because I was talked into it after that variant was demonstrated (by someone else) to a positive audience.
People liked it. RSpec took off. Whoops.
I later said on twitter, jokingly, that RSpec was a huge troll. That was kind of a joke on a joke. RSpec wasn't a joke, but I didn't build it for actual use. That was a happy accident. That said, it's a great tool these days, if a bit heavy. And it has certainly served my original wish of teaching many people TDD very well.
My $0.02 on the "maybe" syntax: if you need this, I suspect your problems are a lot larger than whether or not an assertion will pass or fail. It's symptom solving.
Thank you for this. It's nice to have it straight from the horses mouth instead of the many different types of RSpec folklore I've heard about its origin.
While this is obviously a joke, I can see it having a limited amount of practical value. Imagine, for example, being tasked with updating a poorly-maintained legacy code base with a large number of indeterminately failing specs containing order dependencies. You could `RSpec::Maybe` everything until you're sure you have the order dependencies resolved, then convert to regular `RSpec::Expectation`s.
Pending is really useful: it can also tell you if a test that you expected to be passing is now failing. It's also useful for hiding output for tests that are temporarily failing, until you fix them all.
I'll often spec out a whole behavior, with ten or fifteen tests, and then mark all but one pending, make that one pass, unmark another one, make that pass, unmark another... it's easier to focus on just the one you're working on rather than 19 other failing outputs.
I can see wondering if this was a joke as 'maybe' is mildly reminiscent of promise[1] and the like but if you got to .on_my_machine and still couldn't figure it out, you got some 'splainin to do. :)
There are valid scenarios for having a test which is expected to fail in some settings. But of course you should always know why a test might fail and be explicit. (Which is exactly what pending and skipped tests are for.)
