Test fallito: sign_in(Fabricate(:user))

I’ve got a spec that started failing a few days ago. It looks like it’s due to something about timzone? I don’t see a way that it’s my plugin’s fault, but maybe I’m missing something?

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
Running Rspec: plugins/discourse-topic-default-tag/spec/requests/actions_controller_spec.rb
Loading plugins while running specs

An error occurred while loading ./plugins/discourse-topic-default-tag/spec/requests/actions_controller_spec.rb.
Failure/Error: UserOption.create!(user_id: id)

NoMethodError:
  undefined method `timezone' for #<UserOption:0x000055dd7af16ca8>
  Did you mean?  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)>'
No examples found.


Finished in 0.00005 seconds (files took 3.52 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

That sounds like you’re missing the timezone column in your user_options table. Have you run migrations recently in your test database? RAILS_ENV=test bin/rake db:migrate

Why, no! No I haven’t. I ran migrations on the dev database, but not test. Thanks, David!

I don’t understand what’s going on now, but it’s likely not as novice as this problem. :wink:

You should get a message when you’re missing migrations

But this will only work if you’re using the rails_helper. I suspect you need to add require "rails_helper" to the top of your spec file. That might resolve the other issues you’re seeing as well.

Edit: hmmm… maybe we should add --require rails_helper to the .rspec file so that it doesn’t need to be added manually :thinking:

That sounds like the kind of stupid error that I would make! Alas, I do have require 'rails_helper'.

Maybe runing ./bin/rake autospec rather than bundle exec rake autospec was my problem, but it’s still failing at travis, and now this spec seems to be doing a bunch of stuff that I don’t understand for my one little spec, but I’ll just wait and see what happens.

Thanks again.

Sto riscontrando un problema con la funzione di aiuto sign_in, qualsiasi aiuto sarebbe molto apprezzato! :exploding_head: :

Quando utilizzata in questo test, non sembra restituire un current_user e fallisce con un errore 403 (invece di un 200)

Sto eseguendo il test in questo modo per isolare il problema, ma non funziona in nessun caso:

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

Se aggiungo un byebug nel controller corrispondente e controllo current_user, questo è nil (da cui il 403, immagino!):

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

C’è un sopra che crea quell’utente? (Non sono abbastanza bravo da ricordare come si chiama o esattamente come si fa. Ah, un fabbricatore, forse. Hai fabbricato quell’utente?

(O forse non l’ho visto, dato che sono sul telefono)

Sì, l’utente è stato creato correttamente. L’oggetto utente è istanziato. Il problema è nel metodo sign_in o legato all’ambiente? (Ma questo dovrebbe essere controllato)

Dopo ulteriori indagini, ho rilevato quanto segue:

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

@env.key?(CURRENT_USER_KEY) è true

quindi current_user assume il valore di @env[CURRENT_USER_KEY]

Tuttavia, il suo valore è nil quando questa riga viene chiamata dal mio controller durante l’esecuzione di un test:

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

    raise Discourse::InvalidAccess.new unless current_user

Non sono sicuro del motivo per cui @env[CURRENT_USER_KEY] risulti nil dopo aver effettuato l’accesso di un utente all’interno dello spec?

Ho notato che durante l’esecuzione del test current_user viene chiamato più volte all’interno di un singolo test e, in un certo punto, questo attributo ha un valore, ma non in ogni chiamata e non quando è realmente necessario.

Hai installato altri plugin che potrebbero interferire con l’oggetto current_user? Ho clonato discourse-follow e quella specifica funziona per me:

❯ 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

Ah, grazie per la verifica, David! Allora deve essere qualcosa di particolare nel mio ambiente di sviluppo!

No, non ci sono altri plugin installati (a parte quelli in bundle e data explorer), ma dato che funziona per te, sono ispirato a configurare una nuova istanza Docker pulita per lo sviluppo e vedere se riesco a farla funzionare con successo lì. Grazie! :beers:

Sì, ho lavorato su docker dev:

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

grazie!!