search for: userspechelper

What are people''s opinions on which of these two styles is better to use? 1) before --------------------------- module UserSpecHelper include GenericSpecHelper def valid_sms_attributes(phone_number="12345") { :phone_number => phone_number } end end describe User, "with phone number" do include UserSpecHelper before(:each) do @user = User.new(valid_sms_attributes) end it &q...

I''ve been going through Pat''s example story and noticed that there was no checking for a bad login. I assume this is because that would have made the article bigger and more complicated than it needed to be. So the question that comes of of this is: How do folks normally handle the negative case? My plan was to just use another scenario, but as a new person to BDD/TDD,

What is the general opinion about fixtures versus mocking and stubbing in model specs? I heard from agile on IRC that they save the database testing for integration testing, but I also see that the caboose sample applicaiton uses fixtures. I also noticed that on the rspec site, it says "Ironically (for the traditional TDD''er) these are the only specs that we feel should actually

...nd revaluating how I wrote them. I have certain models in which validation requires the presence of an associated model, which itself needs to be valid(validates_presence_of and validates_associated). When I wrote the specs, I wrote helpers for the attributes instead of fixtures, like so: module UserSpecHelper def valid_user_attributes { :email => "test at here.com", :password => "tttttt", :password_confirmation => "tttttt" } end end If the model had a required associated model, I''d also add some valid attribute helpers...

Testing models is great and would not be able to create anything without it, but I am finding testing the controllers and views is a pain. Rest based controllers don''t seem to change that much when compared to the auto-generated code that obviously works. As for views I fail to see why testing it with a mock model does anything. Nothing is ensuring that when changes are made to the

Sorry, lots of questions these days. Is there a normal approach for preconditions? In JUnit, I might put a few assertions in the setUp() just to make sure that the test ''data'' I''ve created meets expectations before going to test it. So, for instance, I''ve got an object that is audited using acts_as_audited and I''d like to test the XML that results

Here''s a controller spec I wrote, it''s for a very simple RESTful controller (well, aren''t all RESTful controllers simple? :) I''ve created a couple spec helper methods to refactor some of the common code...for example, require_login_and_correct_user creates two specifications: one for when the user isn''t logged in, and one when the user is logged in but