On Wednesday, January 27, 2016 at 10:46:39 AM UTC+1, Ruby-Forum.com User wrote: > > But if so, @user from fixtures should also have > reset_token now (if its reset_digest was influenced by create action > (specifically create_reset_digest method). Can someone please take a > look? >
I am also studying the same tutorial and I may have an explanation if you do not mind the fact that if you are lucky I am as an inexperienced user as you are. Hopefully there will be someone more experienced than us who check my answer in case I wrote bullshit. You may find a similar context for your question at chapter 8 when a remember_token is created and the book says that "there’s no way for the test to get access to it". As far as I have understood, the point is in the call of 'user.remember_token' or, in your case, 'user.reset_token'. In the fixtures, user does not have a reset_token: look at the fixtures and you will see, there is not a reset_token attribute. It is true that it takes that attribute dynamically via the create action of the controller, but once you exit from the action, user is back again the user from the fixtures, with no reset_token attribute (that's why is defined 'virtual': once you exit from the create action of the controller it is lost). Using 'assigns(:user)' let you have access directly to the user defined in the create action and retrieve the token. Does it make sense? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/2f506564-352d-41b7-958b-32b8477d6522%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
