Phil Pirozhkov

> I wonder if this entire class of problems could be solved by disallowing database access during spec setup? Or having separate rw and read-only connections, and only allowing read-only...

> Unable to configure with AllowedReceivers I don't really think this option is necessary at all. We're detecting calls made outside of the suite context, and I think they'd better...

> The problem would be better handled at run time. I can only think of `before(:suite) { DatabaseCleaner.clean_with(:deletion/:truncation) }`. > couldn't find any real offenses I must confess, it hit...

I understand what you mean, this in the best case renders this `allow` line useless. For those specs that have do depend on the internal implementation, I guess `allow`+`expect` is...

`invoke` 👍 There's a comparable [`send_message`](https://github.com/zverok/saharspec#send_messageobject-method-matcher) just in case.

> > https://github.com/rubocop/rubocop/pull/10831 is required to resolve the build errors. > Does it also mean that we should bump the minimum required version? But it's not released yet. This is...

Sounds great. Would you like to open a PR with such a cop? It should be an easy one. There's `RSpec/ContextDescription` for the reference.

Can be easier - block can return the return value of their last statement, so in theory this could be just: ```ruby it "does something" do answers = create(:questionnaire) do...

How about ```ruby it "does something" do questionnaire = create(:questionnaire) answers = create_list(:answer, 4, questionnaire: questionnaire) responses = create_list(:responses, 4, questionnaire: questionnaire) expect(somePolicy.resolve(current_user)).to eq answers expect(something_else).to eq responses end ```...

The subject under test is some request, and it makes a call to a service with certain values, and we tap in to get those values and make sure the...