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 rea

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.