Refactor to User Model

Upcase
1
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/refactor-to-user-model
2

Shouldnā€™t we be unit testing the new User model before writing it? If weā€™re doing TDD, it feels a bit wrong to use only the features to test this.

2 Likes
3

Is there a reason why we donā€™t create a User model with has_many :todos?

I mean, doing that would require more steps:

  • Create a User migration with email:string and has_many :todos
  • Create a Todo migration that removes email and adds a reference to user
    • For production, we would first run a task that creates users/associations based on emails currently stored in todos.
  • We can still look for session[:current_email], but we can change that to session[:user_id], since we need to locate a User record on session create.

I guess using a Ruby class is the most minimal code required to get the tests to pass, and offering the minimal amount of changes. Could that be the reason then?

4

Yes we could create a ActiveRecord model with has_many. But I guess the point here is to go through the Red-Green-Refactor steps to get a sense of what kind of code is needed to make a featureā€™s tests pass, then how to dispatch the responsibilities we created to proper objects (using these tests to guard us from crashing the feature)
So not using an ActiveRecord object here is just an excuse to get used to that workflow. In another context, the new object could be a Service.