Comment effectuer le test rspec put controller de scaffold

c'est le message de l'auteur de la question. J'ai dû aller un peu dans le terrier du lapin pour comprendre les multiples problèmes qui se chevauchent ici, donc je voulais juste faire un rapport sur la solution que j'ai trouvée.

tldr; il est trop difficile d'essayer de confirmer que chaque attribut important revient inchangé d'un PUT. Il suffit de vérifier que l'attribut modifié est ce que vous attendez.

Les problèmes que j'ai rencontré:

1. FactoryGirl.attributes_for ne renvoie pas toutes les valeurs, donc FactoryGirl: attributes_for ne me donne pas les attributs associés suggère d'utiliser (Factory.build :company).attributes.symbolize_keys , ce qui finit par créer de nouveaux problèmes.
2. spécifiquement, les Rails 4.1 enums montrent comme des entiers au lieu des valeurs enum, comme rapporté ici: https://github.com/thoughtbot/factory_girl/issues/680
3. il s'avère que le BigDecimal question était un rouge hareng, causé par un bug dans le matcher rspec qui produit des diffs incorrects. Ceci a été établi ici: https://github.com/rspec/rspec-core/issues/1649
4. la défaillance réelle de l'apparieur est causée par des valeurs de Date qui ne correspondent pas. Cela est dû au fait que le temps retourné est différent, mais il ne s'affiche pas parce que Date.inspect ne montre pas millisecondes.
5. j'ai contourné ces problèmes avec une méthode de hachage patché de singe qui symbolise les clés et les valeurs stringifs.

Voici la méthode Hash, qui pourrait aller dans rails_spec.rb:

class Hash
  def symbolize_and_stringify
    Hash[
      self
      .delete_if { |k, v| %w[id created_at updated_at].member?(k) }
      .map { |k, v| [k.to_sym, v.to_s] }
    ]
  end
end

alternativement (et peut-être de préférence) j'aurais pu écrire un RSpec personnalisé que itère à travers chaque attribut et compare leurs valeurs individuellement, ce qui aurait fonctionné autour de la question de date. C'était l'approche de la méthode assert_records_values au bas de la réponse que j'ai choisie par @Benjamin_Sinclaire (pour qui, je vous remercie).

cependant, j'ai décidé à la place de revenir à l'approche beaucoup, beaucoup plus simple de rester avec attributes_for et juste en comparant l'attribut que j'ai changé. Plus précisément:

  let(:valid_attributes) { FactoryGirl.attributes_for(:company) }
  let(:valid_session) { {} }

  describe "PUT update" do
    describe "with valid params" do
      let(:new_attributes) { FactoryGirl.attributes_for(:company, name: 'New Name') }

      it "updates the requested company" do
        company = Company.create! valid_attributes
        put :update, {:id => company.to_param, :company => new_attributes}, valid_session
        company.reload
        expect(assigns(:company).attributes['name']).to match(new_attributes[:name])
      end

j'espère que ce billet permettra aux autres de ne pas répéter mes recherches.

Eh bien, j'ai fait quelque chose de plus simple, J'utilise un manufacturier, mais je suis assez sûr que C'est la même chose avec FactoryGirl:

  let(:new_attributes) ( { "phone" => 87276251 } )

  it "updates the requested patient" do
    patient = Fabricate :patient
    put :update, id: patient.to_param, patient: new_attributes
    patient.reload
    # skip("Add assertions for updated state")
    expect(patient.attributes).to include( { "phone" => 87276251 } )
  end

aussi, je ne suis pas sûr pourquoi vous construisez une nouvelle usine, mettre verbe est censé ajouter de nouveaux trucs, Non?. Et ce que vous testez si ce que vous avez ajouté en premier lieu ( new_attributes ), se trouve exister après le put dans le même modèle.

ce code peut être utilisé pour résoudre vos deux problèmes:

it "updates the requested patient" do
  patient = Patient.create! valid_attributes
  patient_before = JSON.parse(patient.to_json).symbolize_keys
  put :update, { :id => patient.to_param, :patient => new_attributes }, valid_session
  patient.reload
  patient_after = JSON.parse(patient.to_json).symbolize_keys
  patient_after.delete(:updated_at)
  patient_after.keys.each do |attribute_name|
    if new_attributes.keys.include? attribute_name
      # expect updated attributes to have changed:
      expect(patient_after[attribute_name]).to eq new_attributes[attribute_name].to_s
    else
      # expect non-updated attributes to not have changed:
      expect(patient_after[attribute_name]).to eq patient_before[attribute_name]
    end
  end
end

il résout le problème de la comparaison des nombres à virgule flottante en convertissant les valeurs en représentation de chaîne de caractères à L'aide de JSON.

il résout également le problème de vérifier que les nouvelles valeurs ont été mises à jour, mais le reste des attributs n'ont pas changé.

Dans mon expérience, cependant, que la complexité augmente, la chose à faire est de vérifier certains l'état de l'objet spécifique au lieu de"s'attendre à ce que les attributs que je ne mets pas à jour ne changent pas". Imaginez, par exemple, que d'autres attributs changent au fur et à mesure que la mise à jour est effectuée dans le contrôleur, comme "éléments restants", "certains attributs de statut"... Vous souhaitez vérifier les changements spécifiques attendus, qui peuvent être plus que les attributs mis à jour.

voici ma façon de tester mis. C'est un extrait de mon notes_controller_spec , l'idée principale doit être claire (dites-moi si non):

RSpec.describe NotesController, :type => :controller do
  let(:note) { FactoryGirl.create(:note) }
  let(:valid_note_params) { FactoryGirl.attributes_for(:note) }
  let(:request_params) { {} }

  ...

  describe "PUT 'update'" do
    subject { put 'update', request_params }

    before(:each) { request_params[:id] = note.id }

    context 'with valid note params' do
      before(:each) { request_params[:note] = valid_note_params }

      it 'updates the note in database' do
        expect{ subject }.to change{ Note.where(valid_note_params).count }.by(1)
      end
    end
  end
end

au lieu de FactoryGirl.build(:company).attributes.symbolize_keys , j'écrirais FactoryGirl.attributes_for(:company) . Il est plus court et ne contient que les paramètres que vous avez spécifiés dans votre usine.

malheureusement, c'est tout ce que je peux dire sur vos questions.

Mais si vous posez BigDecimal equality vérifiez sur la couche de base de données en écrivant dans le style comme

expect{ subject }.to change{ Note.where(valid_note_params).count }.by(1)

ça peut marcher pour vous.

Test de l'application rails avec rspec-gem rails. Créé à l'échafaudage de l'utilisateur. Vous devez maintenant passer tous les exemples de user_controller_spec.rb

cela a déjà été écrit par le générateur d'échafaudages. Il suffit de mettre en œuvre

let(:valid_attributes){ hash_of_your_attributes} .. like below
let(:valid_attributes) {{ first_name: "Virender", last_name: "Sehwag", gender: "Male"}
  } 

va maintenant passer de nombreux exemples de ce fichier.

pour invalid_attributes assurez - vous d'ajouter les validations sur l'un des champs et

let(:invalid_attributes) {{first_name: "br"}
  }

dans le les utilisateurs du modèle .. la validation pour first_name est as = >

  validates :first_name, length: {minimum: 5}, allow_blank: true

maintenant tous les exemples créés par les générateurs passeront pour ce controller_spec