Episode 4 - Creating a Brand

Vlcsnap-2009-09-08-10h16m35s23

Click on image above for a preview

Released: Sep 08, 2009, Running time: 27 min

In this episode:

Adding the “create” feature for a Brand: write the feature, write the specs, make specs pass, watch feature pass. Done!

Tags: cucumber, rspec, mockups, controller

Add to cart$5.00
  • Share

It turns out Episode 3 was not titled very apropriately since we only get half way into adding the Brand.

In this episode we actually add the new and create actions for the Brand resource.

Covered in this episode:

  1. Writing the feature to create a Brand.
  2. Speccing the new and create controller actions.
  3. Implementing the actions.
  4. Watching the specs and features pass.

Check out the new episode to see how we add the “Edit” feature.

Screenshots

  • Vlcsnap-2009-09-08-10h17m02s38
  • Vlcsnap-2009-09-08-10h17m06s0
  • Vlcsnap-2009-09-08-10h17m11s119
  • Vlcsnap-2009-09-08-10h17m23s0
  • Vlcsnap-2009-09-08-10h17m34s93
  • Vlcsnap-2009-09-08-10h18m55s123
  • Vlcsnap-2009-09-08-10h19m31s222

5 comments

check out “git add .”
makes things easier

In reply to Ray

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.

In reply to Istvan Hoka

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

In reply to Ray

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

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.

Commenting is disabled.