shoulda-matchers: undefined method `type' for nil:NilClass when using validate_uniqueness_of(...).scoped_to(AnArray)

+1 Having the exact same issue as the others. I had a Active Record 5 related issue so I thought this might be related to using Active Record 5, but it seems that this is not the case.

Any chance of a release soon? Been about a half a year since the last update…

Same here… we had worked around this in 2.x by using association**_id**:

it { is_expected.to validate_uniqueness_of(:a_field).scoped_to(:association_id).case_insensitive}

However, moving to 3.1.1 just now has removed that:

YourModel did not properly validate that :a_field is case-insensitively unique within the scope of :association_id. Expected the validation to be scoped to :association_id, but it was scoped to :association instead.

Just use the association_id validates_uniqueness_of :a_field, scope: :association_id

I was able to get this to work when using attributes on the table itself:

# app/models/saved_view.rb
  validates :name, presence: true, uniqueness: { scope: :user_id }

# spec/models.saved_view.rb
    it { is_expected.to validate_uniqueness_of(:name).scoped_to(:user_id) }

If you’re willing to live with the attributes v. association object, this will pass

Unfortunately, there’s so much stuff that we are including in the next release that we’ve decided to hold off on fixing this for now. I’ll keep this open for now but we’ll have to swing back around and include a fix for this in a future release.

if someone needs a temporary workaround for that:

• using rspec, factory_bot (feel free to use something different)
• parent is the referenced model
• referenced model and name have to be unique

require 'rails_helper'

RSpec.describe SomeRecord, type: :model do
  ...
  describe 'extended validation' do
    let!(:some_record_parent) { create(:some_record_parent) }
    ... 
    context 'some_record already exists' do
      let(:some_record) {
        create(:some_record, some_record_parent: some_record_parent)
      }

      it 'fails when adding some_record twice' do
        expect { create(:some_record, some_record_parent: some_record_parent, name: some_record.name) }
          .to raise_error(ActiveRecord::RecordInvalid, 'Validation failed: Name has already been taken')
      end
    end
  end
end

I’ve been noodling on this the past few days. The reason why we haven’t tackled this problem yet is it’s a difficult problem, and it’s difficult because because associations are way more variable than non-associations. The most complicated part of the uniqueness matcher is that it needs to generate unique values for the attributes that are involved in the validation (or at least the ones you care about), so that it can test the validation thoroughly. For instance, if you have a Post model and it validates uniqueness of slug scoped to blog_id, it tests these scenarios:

• What happens if you have two posts with the same slug and blog_id — does the validation fail?
• What happens if you have two posts with a different slug but the same blog_id — does the validation pass?
• What happens if you have two posts with the same slug but a different blog_id — does the validation pass?

To do this, the uniqueness matcher needs to know how to generate a record with a “different” (i.e. unique) value for one or more attributes. This is relatively easy to do for non-associations: if the attribute is a string column, call .next on the string; if it’s a number column, add 1; if it’s a time column, add 1 second; etc. But associations are totally separate ActiveRecord objects, and while the simplest way to create a unique version of another record is to .dup it and save it to get an object with a different id, that’s probably not going to work, especially if that model has a uniqueness validation on it. Maybe the matcher could do something like look inside that model, see which attributes are unique, and try to generate unique values for those attributes — but that would add complexity I don’t think we need. It’s probably less code and a better experience in the long run to have you as the developer provide unique values for association attributes through another qualifier. I’m thinking that this could look something like this:

# Presumably this would already have a blog
subject { FactoryGirl.build(:post) }

it do
  should validate_uniqueness_of(:slug)
    .scoped_to(:blog)
    .using_unique_value_for(:blog) { FactoryGirl.create(:blog) }
end

and if you had multiple association scopes:

# Presumably this would already have a blog
subject { FactoryGirl.build(:company) }

it do
  should validate_uniqueness_of(:name)
    .scoped_to(:profile, :user)
    .using_unique_value_for(:profile) { FactoryGirl.create(:profile) }
    .using_unique_value_for(:user) { FactoryGirl.create(:user) }
end

I don’t have any code written to support this yet as I’m still playing around with this. Would this seem like a good solution, though?

I’m running into this same bug with a validation intended to prevent accidentally creating two identical relationships. Wound up just checking the IDs rather than the related object to work around.

Will create a PR then

I’m not even sure if this issue still occurs. I’ve first opened this error because it failed to validate scoped to more than one association at the same time. I do vaguely remember that scoping to a single association worked at the moment in time. I’ll try to create a demo app that reproduces this error, so we are clear in it. Based on comments, I think we potentially have 2 issues in a single place. I’ll come back with demo repository whenever I have it.

+1

I am seeing this even without scoped_to on any association, just a basic uniqueness validation:

# model
validates :user, uniqueness: true

# test
it { should validate_uniqueness_of(:user) }

Failure/Error: it { should validate_uniqueness_of(:user) }

NoMethodError:
  undefined method `type' for nil:NilClass
# /Users/bbugh/.rvm/gems/ruby-2.6.2/gems/shoulda-matchers-4.0.1/lib/shoulda/matchers/active_record/validate_uniqueness_of_matcher.rb:809:in `dummy_scalar_value_for'
# /Users/bbugh/.rvm/gems/ruby-2.6.2/gems/shoulda-matchers-4.0.1/lib/shoulda/matchers/active_record/validate_uniqueness_of_matcher.rb:804:in `dummy_value_for'
# /Users/bbugh/.rvm/gems/ruby-2.6.2/gems/shoulda-matchers-4.0.1/lib/shoulda/matchers/active_record/validate_uniqueness_of_matcher.rb:567:in `arbitrary_non_blank_value'
# /Users/bbugh/.rvm/gems/ruby-2.6.2/gems/shoulda-matchers-4.0.1/lib/shoulda/matchers/active_record/validate_uniqueness_of_matcher.rb:684:in `matches_uniqueness_without_scopes?'
# /Users/bbugh/.rvm/gems/ruby-2.6.2/gems/shoulda-matchers-4.0.1/lib/shoulda/matchers/active_record/validate_uniqueness_of_matcher.rb:330:in `matches?'
# ./spec/models/organization_user_spec.rb:14:in `block (3 levels) in <top (required)>'

Just experienced this, bit of a bummer 👍

The uniqueness matcher doesn’t support using associations as scopes. I’m not really sure this is what you want to do, anyway – don’t you want to use id columns instead?

@bbugh I think you might be right about that, I have definitely noticed some oddities in the past. I will put this in the queue for the next version.

+1