Rspec Spott: ActiveRecord::AssociationTypeMismatch

Ich bin neu in Rspec und versuchen, ein test für ein Benutzer-Profil. Profil belongs_to Benutzer.

Nun, ich habe eine API-integration mit einem Drittanbieter-Website, die funktioniert durch die Benutzer-Modell, aber einige der Informationen, die für die API-link enthalten ist, im Profil, so habe ich eine "after_update" - filter auf Profil, die Auskunft über die übergeordneten Benutzer zu speichern, die Trigger eine Aktualisierung des API.

Ich versuche, einen test schreiben, und ich bin immer ein ActiveRecord::AssociationTypeMismatch. Der Grund ist ich bin mit einem mock-Benutzer, aber ich bin versucht zu testen, wenn das Profil aktualisiert wird, sendet es :save to User. Plus, der Benutzer-Modell verfügt über eine Bestätigungs-E-Mail-Prozess und die afformentioned API-Aufrufe im Prozess erstellen, so ist es wirklich nicht ideal ist, tatsächlich erstellt einen Benutzer einfach, diese heraus zu testen.

Hier mein test:

it "should save the parent user object after it is saved" do
    user = double('user', :save => true )
    profile = Profile.create( :first_name => 'John', :last_name => 'Doe' )
    profile.user = user

    user.should_receive(:save)
end

So, klar die ActiveRecord-Fehler wird verursacht, indem Sie versuchen, ordnen Sie ein mock-Benutzer mit einem Profil, das rechnet mit einem realen Benutzer zugeordnet werden.

Meine Frage ist, wie vermeiden Sie diese Art von problem schriftlich Schienen-tests? Alles was ich will, dieses testen zu tun ist, stellen Sie sicher, Profil-Aufrufe :sparen, übergeordnete Benutzer. Ist es ein schlauer Weg, dies zu tun, oder einen workaround für die ActiveRecord-Fehler?

Dank!

  • Ich persönlich würde so etwas wie factory_girl zum Handwerk eines bereits bestätigten User-Objekt, und legen Sie dann die save Erwartung auf, dass. Sind Sie nicht in der Lage, gefälschte eine bestätigte Benutzer ohne den Umweg über die e-mail-Prozess? Gang setzt einige Alarme mit Bezug auf das code-design.
  • Gut, Ihren Vorschlag endete als der Weg, den ich gehen musste. Ich war in der Lage zu isolieren, die API wollte ich nicht rief, indem er dem controller nicht zu trigger-Aufruf in der Testumgebung zu testen, so lassen Sie mich die Arbeit mit Factory-Objekte, wie erwartet. Allerdings musste ich wiederum die API-Aktionen wieder auf um zu testen Integrationen, so dass am Ende nur ich diesen Ansatz aufgegeben und bin so dass die sandbox-Umgebung für die API zu bekommen, die voll von junk-Daten, die ich habe, um in regelmäßigen Abständen. Nicht, was ich hätte es vorgezogen, aber es lässt mich testen.
InformationsquelleAutor Andrew | 2011-02-03
  1. 11

    Sollten Sie in der Lage sein zu verwenden mock_model für diese:

    it "should save the parent user object after it is saved" do
  user = mock_model(User)
  user.should_receive(:save).and_return(true)
  profile = Profile.create( :first_name => 'John', :last_name => 'Doe' )
  profile.user = user
end
    • Ich habe versucht, und es hat nicht funktioniert.
    • Was speziell?
    • beachten Sie, dass der rspec-v3 mock_model wurde extrahiert in ein separates gem rspec-activemodel-mocks finden Sie unter relishapp.com/rspec/rspec-rails/v/3-2/docs/...
    InformationsquelleAutor zetetic
  2. 4

    Fand ich nur so, ich war in der Lage, dieses problem zu umgehen, war die Verwendung eines Factory-Benutzer statt eines mock. Das ist frustrierend, aber beim testen des callbacks zwischen zwei ActiveRecord-Modelle, die Sie haben zu verwenden, die realen Modelle oder anderes speichern Aufrufe fehl, ist der Lebenszyklus wird nicht passieren, und die Rückrufe können nicht getestet werden.

    • Sollte nicht callbacks getestet werden die relevanten Modell-spec?
    • Sie haben mein Leben gerettet
    InformationsquelleAutor Andrew
Schreibe einen Kommentar