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 interact with the database." (http://rspec.rubyforge.org/documentation/rails/index.html). Thoughts?
David Chelimsky
2007-Sep-04 13:32 UTC
[rspec-users] Model Specs: Fixtures vs Mocks + Stubs?
On 9/4/07, Lance Carlson <lancecarlson at gmail.com> wrote:> 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 interact with the database."I wrote that bit - but it doesn''t suggest that you should use fixtures or not. If I''m going to the DB I generally create the model objects I want right in the examples. re: fixtures - the argument against is that they are a pain to maintain - but there have been some recent developments like http://code.google.com/p/fixture-scenarios/ that seem promising. With the recent addition of Story Runner (in trunk), I''m exploring more and more the ideas espoused by Jay Fields on his blog re: mocking declarative API calls to AR (see http://blog.jayfields.com/2006/12/rails-unit-testing-activerecord.html) to support super-fast object-level examples in concert w/ end-to-end examples in Story Runner. So you have two separate issues here: 1. db or not db 2. if db, fixtures or not fixtures I doubt you''ll find general consensus on either question. Good luck! Cheers, David
Ok, so to extend this issue, I''m attempting to use mocks and stubs on
my model specs. I''ve got some questions though.. here is my code:
module UserSpecHelper
def mock_user(user)
@user = mock_model(User)
if user == :lance || user == :account_owner
@user.stub!(:login).and_return(''lance'')
elsif user == :bob || user == :normal_user
@user.stub!(:login).and_return(''bob'')
@user.stub!(:email).and_return(''test at test.com'')
@user.stub!(:account).and_return(mock_account(:lances))
end
@user
end
def mock_account(account)
@account = mock_model(Account)
if account == :lances
end
@account
end
end
describe "An account owner" do
include UserSpecHelper
before(:each) do
@user = mock_user(:lance)
end
it "indicate they own the account" do
@user.should_receive(:is_account_owner?).and_return(true)
@user.is_account_owner?.should be_true
end
end
1st question: Am I approaching the mocking and stubbing correctly?
2nd question: I feel like I''m not actually testing the
is_account_owner? code which I want to do, but can''t figure out how to
test the implementation. I feel like I want to stub account_id instead
of account and have it rely on my model to supply the account method
automatically. Where am I going wrong?
TIA
On 9/4/07, David Chelimsky <dchelimsky at gmail.com>
wrote:> On 9/4/07, Lance Carlson <lancecarlson at gmail.com> wrote:
> > 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 interact with the
database."
>
> I wrote that bit - but it doesn''t suggest that you should use
fixtures
> or not. If I''m going to the DB I generally create the model
objects I
> want right in the examples.
>
> re: fixtures - the argument against is that they are a pain to
> maintain - but there have been some recent developments like
> http://code.google.com/p/fixture-scenarios/ that seem promising.
>
> With the recent addition of Story Runner (in trunk), I''m exploring
> more and more the ideas espoused by Jay Fields on his blog re: mocking
> declarative API calls to AR (see
> http://blog.jayfields.com/2006/12/rails-unit-testing-activerecord.html)
> to support super-fast object-level examples in concert w/ end-to-end
> examples in Story Runner.
>
> So you have two separate issues here:
>
> 1. db or not db
> 2. if db, fixtures or not fixtures
>
> I doubt you''ll find general consensus on either question. Good
luck!
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Or am I to assume that rails is doing it''s job and that the associations I created in my models are working as they should? On 9/4/07, Lance Carlson <lancecarlson at gmail.com> wrote:> Ok, so to extend this issue, I''m attempting to use mocks and stubs on > my model specs. I''ve got some questions though.. here is my code: > > module UserSpecHelper > def mock_user(user) > @user = mock_model(User) > if user == :lance || user == :account_owner > @user.stub!(:login).and_return(''lance'') > elsif user == :bob || user == :normal_user > @user.stub!(:login).and_return(''bob'') > @user.stub!(:email).and_return(''test at test.com'') > @user.stub!(:account).and_return(mock_account(:lances)) > end > @user > end > > def mock_account(account) > @account = mock_model(Account) > if account == :lances > > end > @account > end > end > > describe "An account owner" do > include UserSpecHelper > > before(:each) do > @user = mock_user(:lance) > end > > it "indicate they own the account" do > @user.should_receive(:is_account_owner?).and_return(true) > > @user.is_account_owner?.should be_true > end > end > > 1st question: Am I approaching the mocking and stubbing correctly? > > 2nd question: I feel like I''m not actually testing the > is_account_owner? code which I want to do, but can''t figure out how to > test the implementation. I feel like I want to stub account_id instead > of account and have it rely on my model to supply the account method > automatically. Where am I going wrong? > > TIA > > On 9/4/07, David Chelimsky <dchelimsky at gmail.com> wrote: > > On 9/4/07, Lance Carlson <lancecarlson at gmail.com> wrote: > > > 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 interact with the database." > > > > I wrote that bit - but it doesn''t suggest that you should use fixtures > > or not. If I''m going to the DB I generally create the model objects I > > want right in the examples. > > > > re: fixtures - the argument against is that they are a pain to > > maintain - but there have been some recent developments like > > http://code.google.com/p/fixture-scenarios/ that seem promising. > > > > With the recent addition of Story Runner (in trunk), I''m exploring > > more and more the ideas espoused by Jay Fields on his blog re: mocking > > declarative API calls to AR (see > > http://blog.jayfields.com/2006/12/rails-unit-testing-activerecord.html) > > to support super-fast object-level examples in concert w/ end-to-end > > examples in Story Runner. > > > > So you have two separate issues here: > > > > 1. db or not db > > 2. if db, fixtures or not fixtures > > > > I doubt you''ll find general consensus on either question. Good luck! > > > > Cheers, > > David > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > >