Marc-André Lafortune

> > In general, we recommend you use the loosest matcher that still specifies the behaviour you care about. Right, I agree with that quote, but only in the context...

Just got more autocorrections for: ```ruby expect(something).to be_a(SomeClass) # corrected to expect(something.is_a?(SomeClass)).to be(true) ``` That's also equally bad, for the same reasons as the rest.

> may choose to be more relaxed when testing private APIs. They may. I'll disagree with the fact that they are testing private APIs 😆.

> I'm not sure I understand. Do you think `is_a?` should be yet another exception to the explicit style? It's getting pretty complicated. Sorry, I haven't looked into the cop,...

I was convinced that `expect(thing).to be_foo` was checking for `== true` but it isn't. 🤯 The [doc](https://relishapp.com/rspec/rspec-expectations/v/2-4/docs/built-in-matchers/predicate-matchers) really seem to imply the contrary, and the error messages too! ``` expected...

> I think it would break a _lot_ of tests if RSpec were to change it. I'm very curious about that, but if so [it might hide bugs](https://github.com/rspec/rspec-core/pull/2736). > Maybe...

> `contain_exactly` and `match_array` are order-independent. Oh, indeed, my bad. Your example is what I should have written.

Good catch on the block 👍 > `expect([-1,2,3]).to all be_positive` Definitely the best 🎉

> I write `if !thing` not `if thing == false` Agreed, usually it doesn't matter. But it might, e.g. `thing&.something?`, or `collection.group_by(&:thing)`. > Perhaps this is a difference between writing...

@pirj have you been able to make progress on this front?