Fehlender Test: sign_in(Fabricate(:user))

pfaffman · 30. März 2020 um 16:33

Ich habe eine Spezifikation, die vor ein paar Tagen angefangen hat, fehlschlagen. Es sieht so aus, als läge es an etwas mit der Zeitzone? Ich sehe keine Möglichkeit, dass mein Plugin dafür verantwortlich ist, aber vielleicht übersehe ich etwas?

require 'rails_helper'

describe TopicDefaultTag::ActionsController do
  before do
    Jobs.run_immediately!
  end

  it 'can list' do
    sign_in(Fabricate(:user))
    get "/topic-default-tag/list.json"
    expect(response.status).to eq(200)
  end
end

Rspec wird ausgeführt: plugins/discourse-topic-default-tag/spec/requests/actions_controller_spec.rb
Plugins werden beim Ausführen der Spezifikationen geladen

Beim Laden von ./plugins/discourse-topic-default-tag/spec/requests/actions_controller_spec.rb ist ein Fehler aufgetreten.
Fehler in der Ausführung: UserOption.create!(user_id: id)

NoMethodError:
  Die Methode `timezone' ist für #<UserOption:0x000055dd7af16ca8> nicht definiert.
  Gemeint war möglicherweise: timeout
# ./app/models/user.rb:1343:in `create_user_option'
# (eval):19:in `block (2 levels) in run_file'
# ./spec/rails_helper.rb:79:in `<top (required)>'
# ./plugins/discourse-topic-default-tag/spec/requests/actions_controller_spec.rb:1:in `require'
# ./plugins/discourse-topic-default-tag/spec/requests/actions_controller_spec.rb:1:in `<top (required)>'
Keine Beispiele gefunden.


Abgeschlossen in 0,00005 Sekunden (Dateien benötigten 3,52 Sekunden zum Laden)
0 Beispiele, 0 Fehler, 1 Fehler außerhalb der Beispiele aufgetreten

david · 30. März 2020 um 16:35

Das klingt so, als würde dir die Zeitzone-Spalte in deiner user_options-Tabelle fehlen. Hast du kürzlich Migrationen in deiner Testdatenbank ausgeführt? RAILS_ENV=test bin/rake db:migrate

pfaffman · 30. März 2020 um 16:43

Wieso, nein! Nein, habe ich nicht. Ich habe Migrations auf der Dev-Datenbank ausgeführt, aber nicht auf der Test-Datenbank. Danke, David!

Ich verstehe gerade nicht, was los ist, aber das Problem ist wahrscheinlich nicht so einfach, wie es scheint.

david · 30. März 2020 um 16:47

Sie sollten eine Meldung erhalten, wenn Ihnen Migrationen fehlen

github.com/discourse/discourse

spec/rails_helper.rb

29b35aa64


      
          begin
            ActiveRecord::Migration.check_pending!
          rescue ActiveRecord::PendingMigrationError
            raise "There are pending migrations, run RAILS_ENV=test bin/rake db:migrate"
          end

Das funktioniert jedoch nur, wenn Sie den rails_helper verwenden. Ich vermute, Sie müssen require "rails_helper" an den Anfang Ihrer Spec-Datei hinzufügen. Das könnte auch die anderen Probleme lösen, die Sie feststellen.

Edit: Hmm … vielleicht sollten wir --require rails_helper zur .rspec-Datei hinzufügen, damit es nicht manuell hinzugefügt werden muss

pfaffman · 30. März 2020 um 17:07

Das klingt nach einem dämlichen Fehler, den ich auch machen würde! Leider habe ich aber require 'rails_helper'.

Vielleicht lag es daran, dass ich ./bin/rake autospec statt bundle exec rake autospec ausgeführt habe, aber es schlägt immer noch bei Travis fehl. Und jetzt führt diese Spezifikation eine ganze Reihe von Aktionen aus, die ich für meine kleine Spezifikation nicht verstehe, aber ich warte einfach ab, was passiert.

Nochmals vielen Dank.

merefield · 23. August 2021 um 07:41

Ich habe ein Problem mit der sign_in-Hilfsfunktion. Jede Hilfe wäre sehr willkommen! :

github.com/discourse/discourse

spec/support/integration_helpers.rb

f1701764a


      
              password_confirmation: honeypot,
              challenge: challenge.reverse
            }
          
            expect(response.status).to eq(200)
          
            body = response.parsed_body
            User.find(body["user_id"])
          end
          
          def sign_in(user)
            get "/session/#{user.encoded_username}/become"
            user
          end
          
          def sign_out
            delete "/session"
          end
          
          def read_secure_session
            id = begin

Wenn sie in diesem Test verwendet wird, scheint sie keinen current_user bereitzustellen und schlägt mit einem 403er-Fehler fehl (anstatt mit 200).

github.com/discourse/discourse-follow

spec/requests/follow_controller_spec.rb

8920cd30b


      
              it "followers" do
                get "/u/#{user2[:username]}/follow/followers.json", :params => { :type => 'followers' }
                
                expect(response.status).to eq(200)
                expect(response.parsed_body[0]['id']).to eq(user1.id)
                expect(response.parsed_body[0]['username']).to eq(user1.username)
              end
            end
            
            it "updates followers" do
              sign_in(user1)
          
              put "/follow/#{user2.username}.json", params: { follow: true }
              expect(response.status).to eq(200)
              expect(response.parsed_body['following']).to eq(true)
            end
          end

Ich führe den Test wie folgt aus, um ihn zu isolieren, aber es funktioniert auch so nicht:

LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32

Wenn ich im entsprechenden Controller ein byebug hinzufüge und nach current_user suche, ist dieser nil (daher der 403, nehme ich an!):

github.com/discourse/discourse-follow

app/controllers/follow/follow_controller.rb

8920cd30b


      
          class Follow::FollowController < ApplicationController
            def index
            end
          
            def update
              params.require(:username)
              params.require(:follow)
          
              raise Discourse::InvalidAccess.new unless current_user
              raise Discourse::InvalidParameters.new if current_user.username == params[:username]
          
              if user = User.find_by(username: params[:username])
                updater = Follow::Updater.new(current_user, user)
                updater.update(params[:follow])
          
                following = user.followers.include?(current_user.id.to_s)
          
                render json: success_json.merge(following: following)
              else

Randomized with seed 50945

[5, 14] in /home/merefield/code/discourse-follow/app/controllers/follow/follow_controller.rb
    5:   def update
    6:     params.require(:username)
    7:     params.require(:follow)
    8:     byebug
    9:
=> 10:     raise Discourse::InvalidAccess.new unless current_user
   11:     raise Discourse::InvalidParameters.new if current_user.username == params[:username]
   12:
   13:     if user = User.find_by(username: params[:username])
   14:       updater = Follow::Updater.new(current_user, user)
(byebug) current_user
nil

pfaffman · 23. August 2021 um 12:22

Hast du da oben ein , das diesen Benutzer erstellt? (Ich bin nicht gut genug, um mich daran zu erinnern, wie das heißt oder wie man es genau macht. Ach ja, ein Fabrikator, vielleicht. Hast du diesen Benutzer fabriziert?

(Oder vielleicht habe ich es nicht gesehen, da ich gerade am Handy bin))

merefield · 23. August 2021 um 12:59

Ja, der Benutzer ist erstellt. Das Benutzerobjekt wurde instanziiert. Das Problem liegt entweder in der sign_in-Methode oder hat etwas mit der Umgebung zu tun? (Aber das sollte kontrolliert werden)

merefield · 24. August 2021 um 15:56

Bei weiterer Untersuchung stelle ich Folgendes fest:

In def current_user (discourse/lib/auth/default_current_user_provider.rb at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse · GitHub)

ist @env.key?(CURRENT_USER_KEY) true.

Somit nimmt current_user den Wert von @env[CURRENT_USER_KEY] an.

Allerdings ist der Wert nil, wenn diese Zeile während eines Testlaufs aus meinem Controller aufgerufen wird:

  def update
    params.require(:username)
    params.require(:follow)

    raise Discourse::InvalidAccess.new unless current_user

Ich bin mir nicht sicher, warum @env[CURRENT_USER_KEY] nach der Anmeldung eines Benutzers innerhalb der Spezifikation nil sein sollte.

Mir fällt auf, dass current_user während des Testlaufs innerhalb nur eines Tests mehrfach aufgerufen wird. Zu einem Zeitpunkt hat dieses Attribut einen Wert, aber nicht bei jedem Aufruf und nicht, wenn es darauf ankommt.

david · 24. August 2021 um 16:02

Haben Sie weitere Plugins installiert, die das current_user-Objekt beeinträchtigen könnten? Ich habe discourse-follow geklont, und dieser Test läuft bei mir erfolgreich:

❯ LOAD_PLUGINS=1 bin/rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb   

Randomized with seed 28704
...

Finished in 0.45075 seconds (files took 3.34 seconds to load)
3 examples, 0 failures

Randomized with seed 28704

merefield · 24. August 2021 um 16:32

Ah, danke für die Überprüfung, David! Es muss also etwas Besonderes an meiner Dev-Umgebung geben!

Nein, es sind keine anderen Plugins installiert (außer den mitgelieferten und dem Data Explorer), aber da es bei dir funktioniert, bin ich inspiriert, eine frische, saubere Docker-Dev-Instanz einzurichten und zu prüfen, ob ich sie dort erfolgreich ausführen kann. Cheers!

merefield · 25. August 2021 um 10:35

Ja, habe an der Docker-Entwicklung gearbeitet:

d/rake plugin:spec["discourse-follow"]

Danke!!

Thema		Antworten	Aufrufe
Discourse plugin tests are failing Development	3	647	10. März 2019
Install discourse on localhost Self-hosting	18	4863	20. September 2017
Unable to run rspec tests for plugins Development	3	119	24. Dezember 2025
Failure/Error: UserOption.create(user_id: id) Development	0	495	17. April 2019
Can't run plugin:spec, SeedFu error Development	4	731	26. Januar 2019

Fehlender Test: sign_in(Fabricate(:user))

Verwandte Themen