Features/find user by reset token interactor #57
Conversation
|
That's correct! You send the user the URL safe unencrypted token but internally that token is hashed when storing it. Awesome work @npauzenga!! |
🍶 🌵Encryptor model needed to support find_user_by_reset_token
| context "when successful" do | ||
| before do | ||
| @user = create(:confirmed_user, reset_digest: token[0]) | ||
| end |
There was a problem hiding this comment.
@enriikke rubocop doesn't like this but I need the user to be instantiated before the subject is called. Using an instance variable seemed like the cleaned way to make this work.
There was a problem hiding this comment.
Oh that darn rubocop! Always nagging 👮
Best practice says you tend to avoid using instance variables, and that's probably why rubocop is complaining. You can approach this in a couple different ways.
One is to not use a variable at all and simply call create in the before block. You only have a single test that is using the variable to compare to the interactor.user. You could argue that you don't really need to validate that though. You can test that you are getting a user back but are not concerned that it was the user you created. You leave that to AR's find_by method.
You could also say: "but I really want to know that I'm getting the right guy". In that case you can make use or rspec's let! (let bang). Our known friend let works by lazy evaluating its block, in contrast let! evaluates before the example is executed.
There was a problem hiding this comment.
Hmm I see what you mean about not concerning ourselves and allocating responsibility to find_by.
Even though ActiveRecord is responsible here, I still have to test the line anyway and I tend to think being more explicit in my expectation is better? Though maybe it's better to really be extra sure not to test things that are already thoroughly tested on their own. That way your tests cover very strictly only your contributions. I'm conflicted.
|
@enriikke, Boom! Green specs. |
…en-interactor Features/find user by reset token interactor
Hey @enriikke what do you think of these specs? Also, I'm right in my thinking that the
Useris stored with the hashed version of the password reset token but we pass the raw version in the link in the email, right?Adapted from your class,
token[0]is hashed,token[1]is raw.