Failing spec: sign_in(Fabricate(:user))

dev
1

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 Like
2

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 Likes
3

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 Likes
4

You should get a message when you’re missing migrations

https://github.com/discourse/discourse/blob/29b35aa64c6e6c954f80004e58d41da9ef37c529/spec/rails_helper.rb#L180-L184

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 Likes
5

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 Likes
6

I’m having an issue with the sign_in helper function, any help very much appreciated! :exploding_head: :

When used in this test, it doesn’t seem to deliver a current_user and fails with a 403 (instead of a 200)

I’m running the test like so to isolate it, but it doesn’t work either way:

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

If I add a byebug in the corresponding controller and check for current_user it is nil (hence the 403 I guess!):

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
7

Do you have a above that creates that user? (I’m not good enough to remember what that’s called or exactly how to do it. Oh, a fabricator, maybe. Did you fabricate that user?

(or maybe I didn’t see, as I’m on my phone)

1 Like
8

Yep, user is fabbed. The user object is instantiated. The problem is within the sign_in method or something to do with the environment? (But that should be controlled)

1 Like
9

On further investigation, I’m find the following:

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

@env.key?(CURRENT_USER_KEY) is true

so current_user takes the value of @env[CURRENT_USER_KEY]

However, its value is nil when this line is called from my controller during a test run:

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

    raise Discourse::InvalidAccess.new unless current_user

Not sure why @env[CURRENT_USER_KEY] would be nil after signing in a user within the spec?

I notice that during the test run current_user is called multiple times during just one test, and at one point this attribute has a value, but not on every call, and not when it matters.

10

Do you have any other plugins installed which could be interfering with the current_user object? I cloned discourse-follow and that spec works for 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 Likes
11

Ah thanks for verifying David! So it must be something perculiar about my dev setup!

No, there are no other plugins installed (outside of bundled ones and data explorer), but on the basis it works for you I’m inspired to set up a fresh clean docker dev instance and see if I can run it successfully there, cheers! :beers:

1 Like
12

Yeah, worked on docker dev:

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

thanks!!

3 Likes
13

This topic was automatically closed after 20 hours. New replies are no longer allowed.