Comment faire pour tester un validateur personnalisé?

J'ai le texte suivant validator:

# Source: http://guides.rubyonrails.org/active_record_validations_callbacks.html#custom-validators
# app/validators/email_validator.rb

class EmailValidator < ActiveModel::EachValidator
  def validate_each(object, attribute, value)
    unless value =~ /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i
      object.errors[attribute] << (options[:message] || "is not formatted properly") 
    end
  end
end

Je voudrais être en mesure de tester cela dans RSpec à l'intérieur de mon répertoire lib. Le problème jusqu'à présent est que je ne suis pas sûr de savoir comment initialiser un EachValidator.

InformationsquelleAutor GTDev | 2011-10-12

42

Voici un rapide spec j'ai frappé vers le haut de ce fichier et ça fonctionne bien. Je pense que le buter pourrait probablement être nettoyé, mais j'espère que ce sera assez pour vous obtenir a commencé.
```
require 'spec_helper'


describe "EmailValidator" do

  before(:each) do
    @validator = EmailValidator.new({:attributes => {}})
    @mock = mock('model')
    @mock.stub("errors").and_return([])
    @mock.errors.stub('[]').and_return({})  
    @mock.errors[].stub('<<')
  end

  it "should validate valid address" do
    @mock.should_not_receive('errors')    
    @validator.validate_each(@mock, "email", "[email protected]")
  end

  it "should validate invalid address" do
    @mock.errors[].should_receive('<<')
    @validator.validate_each(@mock, "email", "notvalid")
  end  
end
```
- Fonctionne très bien. Ne savent pas à propos de se moquer de('model') malade, essayez d'en apprendre plus à ce sujet.
- rspec.info/documentation/mocks Qui est l'ancien RSpec de la documentation, mais la maquette constructeur reste le même. le modèle n'est qu'un identifiant pour la maquette.
- Vous pouvez aussi le faire fonctionnellement avec les usines.
- Je pense qu'une usine est exagéré. Nous voulons juste une classe vide pour contenir les erreurs de tableau.
- Il fonctionne très bien! J'ai juste fait un autre de stub: @modèle = se moquer de('model', des erreurs: Activerecord::des Erreurs.nouveau({}))
- Sur les nouvelles versions de Rails (je suis en utilisant 4.1), vous aurez besoin de spécifier des attributs à votre programme de validation pour éviter un ArgumentError - il n'a pas d'importance ce que vous transmettez en tant que les attributs ne sont pas vides, donc quelque chose comme @validator = EmailValidator.new({:attributes => { :foo => :bar }}) fera l'affaire.
InformationsquelleAutor Gazler
67

Je ne suis pas un grand fan de l'autre approche, car il relie le test de trop près à la mise en œuvre. Aussi, il est assez dur à suivre. C'est l'approche que j'ai finalement utiliser. Veuillez garder à l'esprit que c'est une simplification grossière de ce que mon validateur fait... voulais juste démontrer de manière plus simple. Il y a certainement des optimisations pour être fait
```
class OmniauthValidator < ActiveModel::Validator
  def validate(record)
    if !record.omniauth_provider.nil? && !%w(facebook github).include?(record.omniauth_provider)
      record.errors[:omniauth_provider] << 'Invalid omniauth provider'
    end
  end
end
```
Associés Spec:
```
require 'spec_helper'

class Validatable
  include ActiveModel::Validations
  validates_with OmniauthValidator
  attr_accessor  :omniauth_provider
end

describe OmniauthValidator do
  subject { Validatable.new }

  context 'without provider' do
    it 'is valid' do
      expect(subject).to be_valid
    end
  end

  context 'with valid provider' do
    it 'is valid' do
      subject.stubs(omniauth_provider: 'facebook')

      expect(subject).to be_valid
    end
  end

  context 'with unused provider' do
    it 'is invalid' do
      subject.stubs(omniauth_provider: 'twitter')

      expect(subject).not_to be_valid
      expect(subject).to have(1).error_on(:omniauth_provider)
    end
  end
end
```
Fondamentalement, mon approche est de créer un faux objet "traitement pouvant être validé", de sorte que nous pouvons vraiment tester les résultats plutôt que d'avoir des attentes pour chaque partie de la mise en œuvre
- J'aime cela parce que je suis un fan de tests de validation à travers le Activerecord::module Validations. Sinon, vous êtes d'attacher le test de ActiveModel de mise en œuvre qui est fragile.
- Avec des Rails 4.1.6, je me suis ":les attributs ne peuvent pas être vide" jusqu'à ce que j'ai changé le validates_with appel d'inclure le nom de l'attribut, par exemple validates_with OmniauthValidator, attributes: 'omniauth_provider'
- Avec des Rails 4.1.7, j'ai été en mesure d'obtenir autour de l' ":attribut ne peut pas être vide" erreur avec validates :omniauth_provider, omniauth: true
- Hey, je serais ravi de voir que les optimisations! Il n'y a pas beaucoup de documentation sur les tests de validation de là-bas.
- Sympa, je pense que c'est une bien meilleure solution que l'on a accepté la réponse.
- Dans rspec 3+ (je pense que c'est quand il a changé), vous devez rspec-collection_matchers gem à l'utilisation de l'ai(1).error_on.
InformationsquelleAutor Neal

Je recommande la création d'une classe anonyme à des fins de test, tels que:

require 'spec_helper'
require 'active_model'
require 'email_validator'

RSpec.describe EmailValidator do
  subject do
    Class.new do
      include ActiveModel::Validations    
      attr_accessor :email
      validates :email, email: true
    end.new
  end

  describe 'empty email addresses' do
    ['', nil].each do |email_address|
      describe "when email address is #{email_address}" do
        it "does not add an error" do
          subject.email = email_address
          subject.validate
          expect(subject.errors[:email]).not_to include 'is not a valid email address'
        end
      end
    end
  end

  describe 'invalid email addresses' do
    ['nope', '@', '[email protected].', '.', ' '].each do |email_address|
      describe "when email address is #{email_address}" do

        it "adds an error" do
          subject.email = email_address
          subject.validate
          expect(subject.errors[:email]).to include 'is not a valid email address'
        end
      end
    end
  end

  describe 'valid email addresses' do
    ['[email protected]', '[email protected]'].each do |email_address|
      describe "when email address is #{email_address}" do
        it "does not add an error" do
          subject.email = email_address
          subject.validate
          expect(subject.errors[:email]).not_to include 'is not a valid email address'
        end
      end
    end
  end
end

Cela permettra d'éviter codé en dur classes telles que Validatable, qui pourrait être référencé dans plusieurs spécialisations, résultant dans l'inattendu et difficile à déboguer comportement en raison des interactions entre les indépendants, les validations, que vous êtes en train de tester, dans l'isolement.

InformationsquelleAutor Kris

À l'aide de Neals excellent exemple comme base je suis venu avec la suivante (pour les Rails et les RSpec 3).

# /spec/lib/slug_validator_spec.rb
require 'rails_helper'

class Validatable
  include ActiveModel::Model
  include ActiveModel::Validations

  attr_accessor :slug

  validates :slug, slug: true
end

RSpec.describe SlugValidator do
  subject { Validatable.new(slug: slug) }

  context 'when the slug is valid' do
    let(:slug) { 'valid' }

    it { is_expected.to be_valid }
  end

  context 'when the slug is less than the minimum allowable length' do
    let(:slug) { 'v' }

    it { is_expected.to_not be_valid }
  end

  context 'when the slug is greater than the maximum allowable length' do
    let(:slug) { 'v' * 64 }

    it { is_expected.to_not be_valid }
  end

  context 'when the slug contains invalid characters' do
    let(:slug) { '*' }

    it { is_expected.to_not be_valid }
  end

  context 'when the slug is a reserved word' do
    let(:slug) { 'blog' }

    it { is_expected.to_not be_valid }
  end
end

Vous n'avez pas besoin d'inclure ActiveModel::Model, aussi il peut être préférable de créer une classe anonyme comme subject { Class.new { include ActiveModel::Validations; attr_accessor :slug; validate :slug, slug: true }.new }

InformationsquelleAutor Joe

Un exemple de plus, avec l'extension d'un objet au lieu de créer de nouvelles classes dans les spécifications. BitcoinAddressValidator est un validateur personnalisé ici.

require 'rails_helper'

module BitcoinAddressTest
  def self.extended(parent)
    class << parent
      include ActiveModel::Validations
      attr_accessor :address
      validates :address, bitcoin_address: true
    end
  end
end

describe BitcoinAddressValidator do
  subject(:model) { Object.new.extend(BitcoinAddressTest) }

  it 'has invalid bitcoin address' do
    model.address = 'invalid-bitcoin-address'
    expect(model.valid?).to be_falsey
    expect(model.errors[:address].size).to eq(1)
  end

  # ...
end

InformationsquelleAutor Vyacheslav Konovalov

Vous devez vous connecter pour publier un commentaire.