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
1 Mi Piace

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

2 Mi Piace

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:

2 Mi Piace

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:

2 Mi Piace

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.

2 Mi Piace

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)

1 Mi Piace

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)

1 Mi Piace

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
2 Mi Piace

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:

1 Mi Piace

Sì, ho lavorato su docker dev:

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

grazie!!

3 Mi Piace

Questo argomento è stato chiuso automaticamente dopo 20 ore. Non sono più consentite nuove risposte.