Closed siruguri closed 7 years ago
You can stub a user and pass that to the post :create call or just leave out the creation when a post is created if you'd like (since the real thing we want to make sure is just that the API call is happening). Up to you. You have full power over how you want to do this :)
Ha, thanks for the power... :)
I'm just curious about what you mean by "stub the user" - do you mean, mock
current_user
to return a stubbed User
instance?
On Wed, Nov 2, 2016 at 1:52 PM, Akansh Murthy notifications@github.com wrote:
You can stub a user and pass that to the post :create call or just leave out the creation when a post is created if you'd like (since the real thing we want to make sure is just that the API call is happening). Up to you. You have full power over how you want to do this :)
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/akanshmurthy/railsbridge-hackathon/issues/14#issuecomment-257995280, or mute the thread https://github.com/notifications/unsubscribe-auth/AACezSGVt7IAHj5bVedwlUy4L3VTOJ9hks5q6PgBgaJpZM4KnmSD .
Yep. Not sure if that would work for the post creation but that's worth a try if you want to go that route. Worst case you can remove the logged in user callback.
In spec'ing
posts_controller
, I need to decide how to deal with post creation which expects acurrent_user
This is to support the spec'ing of the creation of a Bitly link when a post is created.
Therefore, I need to somehow have a user in the db - or change the code to not require a logged in user. The latter is easier, but I'd rather leave in that logic, and use
fixtures
to create test db records, as fixtures are a simpler concept than going through the FactoryGirl abstraction.Any thoughts, comments?