Episode 4 - Creating a Brand

check out “git add .”
makes things easier

The problem with using “git add .” is it quickly becomes a habit and you no longer pay attention to what gets added. You end up committing log files, compiled assets (like minified CSS or JS) etc.

I consider it good practice to manually add each changed and new file so you make sure you want to commit it. Of course, it is cumbersome to type in each path, but shell completion helps a lot, or configuring your terminal to copy text on selection and pasting on middle-click.

The middle ground would be to add subdirectories which you are confident won’t contain junk. For instance “gid add app/models” or “git add db/migrate” are reasonably safe to use.

I just noticed something: Why do you guys use

def post_with_valid_attributes
  @brand.should_receive(:save).and_return(true)
  post :create, :brand => { :name => 'a_new_brand' }
end

instead of

def post_with_valid_attributes
  @brand.stub(:save).and_return(true)
  post :create, :brand => { :name => 'a_new_brand' }
end

sorry formatting went very, very wrong, but you should get my point

Using should_receive enforces that the :save message has to be sent for the example to pass. Using stub would make the example pass in a case when all the rest of the expectations are met, but the code never calls save.

Another way to put it is that the create action is all about calling :save, and since we don’t have a a separate example where we set it as an expectation, we bundle the expectation into the helper method.