Should implicit default values have valid expectations? about shoulda-matchers

[matsales28]

We're not enabling users to make expectations based on the default values of the framework. The test you provided, with touch(false) as a modifier, as an example, passes because of the way we are dealing with boolean missing values as you mentioned, and that might not be the best way to do it, I agree with you on that point. However, I don't think making this change will be worth it, as it will be a breaking change that will add little value to the gem, as we don't often check the default values of configurations.

But I think, especially for newly introduced matchers or qualifiers, that we should make expectations based on the qualifiers used in the spec, even if those qualifiers are defined or not in the framework defaults because they can be overridden at the application level.

Allowing such expectations to pass even without explicit definitions in the association is valuable. It provides flexibility and aligns with the expectation that users can customize and override these settings at the application level.

# app/models/author.rb

class Author < ApplicationRecord
  has_many :articles
end

# config/...

config.active_record.strict_loading_by_default = true

RSpec.describe Author do
  it { is_expected.to have_many(:articles).strict_loading(true) }
  # => this expectation will fail.
end

I'd love to hear your thoughts on this @VSPPedro, as you have more experience maintaining the gem and might have great insights to share.

[VSPPedro]

I don't believe it's worth the trouble, but I'm more than happy to review any PRs aiming to make this change.

So, I don't have a strong opinion on this. Sorry.

With that said, excellent review, @matsales28. I couldn't have conducted a more comprehensive one myself.

[rhannequin]

Thank you @matsales28, this makes complete sense. I might have been confused with the fact that strict loading can be configured on several levels on the application, as you mentioned here, and I thought my example was passing because we wanted to support for implicit framework defaults.
But now I understand better, especially what you mentioned about flexibility. I was conscious such a change would be a very breaking one, and that we don't want to introduce a breaking change for any reason.

I will let @VSPPedro share their point of view to gain experience and insights, and then I'm happy to either change this issue or close it, and get back to improving #1607.

[matsales28]

With that said, we should not make the way we typecast the Boolean values a priority; it's really up to you. Feel free to do so if you are very interested in working on this. Otherwise, I'd recommend continuing the work on #1607 as it's a valuable addition to gem.