Hi! I''m developing a rails applicaton with specify-before approach, with nice results so far. I use mocks and stubs in both Controller and views tests, but the main issue is with model testing. Since I''ve seen many examples here and there, I don''t know if the right way is to use fixtures or not at all (in model specs). Atm, I''m using them, but I don''t know if I should use mocks for associations, all real fixture data... This example http://rspec.rubyforge.org/documentation/rails/writing/models.html uses both approachs (data generated on setup (but no mocks), and data from fixtures). Please, help me! Apart from that, I really like this way of testing. I just want to do it the right way. Regards, Rodrigo.
On 12/21/06, Rodrigo Alvarez Fern?ndez <papipo at gmail.com> wrote:> Hi! > > I''m developing a rails applicaton with specify-before approach, with > nice results so far. > > I use mocks and stubs in both Controller and views tests, but the main > issue is with model testing. Since I''ve seen many examples here and > there, I don''t know if the right way is to use fixtures or not at all > (in model specs). > > Atm, I''m using them, but I don''t know if I should use mocks for > associations, all real fixture data... > > This example http://rspec.rubyforge.org/documentation/rails/writing/models.html > uses both approachs (data generated on setup (but no mocks), and data > from fixtures). > > Please, help me! > > Apart from that, I really like this way of testing. I just want to do > it the right way.The "right" way doesn''t really exist. It depends largely on the nature and complexity of your app. That said, my personal preference is to avoid fixtures and just create what I need in each spec. That''s because I like to see everything I need to understand the context. This approach creates more duplication in specs, but less binding between them. For me, the isolation is *usually* more important than the duplication. David> > Regards, > Rodrigo. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On 12/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:> On 12/21/06, Rodrigo Alvarez Fern?ndez <papipo at gmail.com> wrote: > > Hi! > > > > I''m developing a rails applicaton with specify-before approach, with > > nice results so far. > > > > I use mocks and stubs in both Controller and views tests, but the main > > issue is with model testing. Since I''ve seen many examples here and > > there, I don''t know if the right way is to use fixtures or not at all > > (in model specs). > > > > Atm, I''m using them, but I don''t know if I should use mocks for > > associations, all real fixture data... > > > > This example http://rspec.rubyforge.org/documentation/rails/writing/models.html > > uses both approachs (data generated on setup (but no mocks), and data > > from fixtures). > > > > Please, help me! > > > > Apart from that, I really like this way of testing. I just want to do > > it the right way. > > The "right" way doesn''t really exist. It depends largely on the nature > and complexity of your app. That said, my personal preference is to > avoid fixtures and just create what I need in each spec. That''s > because I like to see everything I need to understand the context. >What about models that need a lot of attributes? Do you create them in the setup method? I suppose that the answer is "yes".> This approach creates more duplication in specs, but less binding > between them. For me, the isolation is *usually* more important than > the duplication. >Thinking about it... with fixtures the environment is shared between specs and tries to satisfy all of them. In fact, you must write specs that "fit" in the fixtures, or write/modify the current fixtures to satisfy the new specs required environment. It seems thar isolating is much better. Thank you.> David
On 12/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:> On 12/21/06, Rodrigo Alvarez Fern?ndez <papipo at gmail.com> wrote: > > Hi! > > > > I''m developing a rails applicaton with specify-before approach, with > > nice results so far. > > > > I use mocks and stubs in both Controller and views tests, but the main > > issue is with model testing. Since I''ve seen many examples here and > > there, I don''t know if the right way is to use fixtures or not at all > > (in model specs). > > > > Atm, I''m using them, but I don''t know if I should use mocks for > > associations, all real fixture data... > > > > This example http://rspec.rubyforge.org/documentation/rails/writing/models.html > > uses both approachs (data generated on setup (but no mocks), and data > > from fixtures). > > > > Please, help me! > > > > Apart from that, I really like this way of testing. I just want to do > > it the right way. > > The "right" way doesn''t really exist. It depends largely on the nature > and complexity of your app. That said, my personal preference is to > avoid fixtures and just create what I need in each spec. That''s > because I like to see everything I need to understand the context.Out of curiosity, do you create AR records in your setup and save them? I almost always just create an object without saving it and stub any finder methods. I know AR is going to do its job and this lets me hit the DB as little as possible, keeping my specs running really fast. Though sometimes I''m not sure if I''m using mocks and stubs too much...trying to find a sweet spot. I think I might write a tutorial on using RSpec to build Rails apps, and then maybe you and Aslak could pick it apart and make recommendations. I could at least get started producing some practical documentation for Rails though. Pat
On 12/21/06, Pat Maddox <pergesu at gmail.com> wrote:> On 12/21/06, David Chelimsky <dchelimsky at gmail.com> wrote: > > On 12/21/06, Rodrigo Alvarez Fern?ndez <papipo at gmail.com> wrote: > > > Hi! > > > > > > I''m developing a rails applicaton with specify-before approach, with > > > nice results so far. > > > > > > I use mocks and stubs in both Controller and views tests, but the main > > > issue is with model testing. Since I''ve seen many examples here and > > > there, I don''t know if the right way is to use fixtures or not at all > > > (in model specs). > > > > > > Atm, I''m using them, but I don''t know if I should use mocks for > > > associations, all real fixture data... > > > > > > This example http://rspec.rubyforge.org/documentation/rails/writing/models.html > > > uses both approachs (data generated on setup (but no mocks), and data > > > from fixtures). > > > > > > Please, help me! > > > > > > Apart from that, I really like this way of testing. I just want to do > > > it the right way. > > > > The "right" way doesn''t really exist. It depends largely on the nature > > and complexity of your app. That said, my personal preference is to > > avoid fixtures and just create what I need in each spec. That''s > > because I like to see everything I need to understand the context. > > Out of curiosity, do you create AR records in your setup and save > them?I only save them when saving them is necessary for the behaviour I''m spec''ing. I''ll also use fixtures on occasion for model classes that have no interesting behaviour (i.e. validations, relationships, etc).>I almost always just create an object without saving it and > stub any finder methods.If you''re talking about non-model specs, I generally stub the finder methods to return mocks (not instances of AR classes)> I know AR is going to do its job and this > lets me hit the DB as little as possible, keeping my specs running > really fast. > > Though sometimes I''m not sure if I''m using mocks and stubs too > much...trying to find a sweet spot.That''s the quest. And it''s going to vary from app to app depending on where the interesting behaviour exists. Sometimes it''s more in the models. Sometimes moreso in the controllers.> > I think I might write a tutorial on using RSpec to build Rails apps, > and then maybe you and Aslak could pick it apart and make > recommendations. I could at least get started producing some > practical documentation for Rails though.That would be great! Thanks Pat. David> > Pat > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
"Since I''ve seen many examples here and there, I don''t know if the right way is to use fixtures or not at all (in model specs)." I''ve personally had a lot of problems with fixtures. One of my current rails apps uses test::unit and fixtures and the fixtures become like spaghetti code very fast. As your tests evolve over time it becomes very hard to manage your fixtures if they aren''t super simple. When your writing a new test you don''t know if you can add to a certain fixture association or not because it may break some other test in your app. If you delete a test that is no longer necessary you are unsure if you can delete the associated fixture data because some other test may depend on it. I also agree with david in that it''s nice to see everything in the context of the test. -- View this message in context: http://www.nabble.com/Advice-with-Model-tests-tf2865964.html#a8012839 Sent from the rspec-users mailing list archive at Nabble.com.