Again, my standard rant:

   expect(me).to.barf.when(i.see(shit.like(this)));

This kind of "stupid language trick" doesn't really add anything. It doesn't make testing any easier compared to an assertion-based test framework. It just rearranges the tokens to something that looks more "English-like". That was a selling point of COBOL, too, and people hate COBOL. I've seen actual custom testing languages that allow you to add a basic integration test in like 2 lines of code. And when testing takes so little effort, adding tests to your workflow becomes as easy as breathing. And that's what you want.

Nope, forget about it. I myself would prefer something that's obvious at a glance like:

    assert a == b
    assert(a == b, "description")

Or if for some reason there's a need to pretty-print the values, then I could accept something like:

    # Patching `==` to be able to pretty-print the values of both ends.
    assert { a == b }

Instead we have a weird attempt at "natural" language. You'd think it would be something like:

    # Simple method that does one obvious thing.
    # Easily greppable. Easily searchable on internet.
    expect(a).to_equal(b)

    # We're already wrapping `a` with `expect`, so what's wrong with using
    # the obvious operators like `==` that already exist in Ruby?
    expect(a) == b

... but nope, instead there's a redundant `.to` added just for the sake of trying to be fancy and creative and showing off composition:

    expect(a).to equal(b)

And then if you even want negation (the equivalent of some `a != b`), then which of these are correct and which are wrong?

    expect(a).not.to be(b)
    expect(a).to not_be(b)
    expect(a).to.not be(b)
    expect(a).to not.be(b)
    expect(a).to_not be(b)
    expect(a).not_to be(b)

Trying to shoehorn English into a DSL like this is a leaky abstraction at best. And not only does it look out of place, but it also makes you wonder if your correctly-written English is actually not the correct combination of keywords and is just checking something different than what you intended.

> And then if you even want negation (the equivalent of some `a != b`), then which of these are correct and which are wrong?

This whole argument just seems incredibly... pedantic. You don't need to wonder which is right and wrong, if you're familiar with the DSL you'll _know_, because you write Ruby, if you're not then the first time you run the spec you'll get a nice error, and then you'll _know_.

RSpec is goddamn gold. You read far, far more code than you write. Tests (and well written Ruby) reading like English is such a velocity boost I wouldn't trade it for the world.

I’m not sure I take from this what your complaint is. You don’t like the way that it looks? Or reads? Or is there a functional complaint I’m missing?

It looks like a pretty standard builder pattern to me.

It may help if you give examples. What language allows an integration test in two lines of code? Can you show me the code? Can you show me the same integration test in rspec so we can see how it is empirically worse?

I’ve done testing in a dozen or so languages/frameworks at this point, and they’ve all felt about the same (except JS, which felt like pulling teeth back when I was doing it). Rspec never struck me as particularly bad, unless you’re looking at intentionally hyperbolic examples.

> You don’t like the way that it looks? Or reads? Or is there a functional complaint I’m missing?

It looks twee, is much more to type, and doesn't get you anything that an assertion-based framework doesn't have except aEsThEtIcS. I loathe the prospect of having to write line after line of that when simple assertions would do the exact same thing just as well.

> What language allows an integration test in two lines of code?

I worked on QRes (ITA Software's reservation system) as a contractor. The integration tests were written in a custom sexpr-based language that was interpreted by the testing framework. You could specify a template that was filled in with generated sample data, and a spec against which the XML response would be checked, and the framework would run the query, get the response, and show you where any part of it differed from the spec. This is proprietary stuff, so I can't show it to you, but it's one of the reasons why QRes is the most elegant enterprise program I'd ever seen, and a joy to maintain. Too bad it had the plug pulled midway through my contract...

        it "revolts when it encounters elegance" do
            expect(poster).to receive(:barf)
            poster.see(shit.like(this))
        end

That would be closer to the proper form.

I've been using rspec for many many years, but more recently switched to minitest. I don't think either has significant advantage over the other. At first minitest feels raw when you're used to rspec's DSL, but it's mostly visual? I didn't run into any limitations or things I'd miss from rspec and grew to like writing just plain Ruby to test Ruby! I think non-Rubyists who have to dip their toes in backend will appreciate that codebase and test suite speak the same language.

I've used both extensively. In my experience, rspec is easier for novices to ramp up, and minitest is easier for experienced developers.

For larger projects and larger team, minitest is better IMHO because it works more cleanly with more kinds of tooling, such large-scale refactoring tools, code quality analysis tools, and AI-coding tools.