While this post is strictly related to ActiveRecord and not Rails in its entirety I thought this was probably the best place to ask. If not I apologise and if someone could point me in the right direction that would be great. I''m putting together a small stand-alone Ruby project (jruby in fact but I''m hoping the premise remains the same) I''ve an alert object which is very straightforward. The <=> method and to_s methods are overridden but other than that there''s nothing more to the object as the alerts are inserted into the database via a completely seperate java process. The problem arises when unit testing. We want to be able to mock out the database if possible but because the implementation of the object is, I guess, done introspectively against the database table so we''ve no model members to work with and the structure depends on the table. Should we just forgo the introspective nature of the object and explicitly map attributes on the Alert object to columns in teh DB so that we can create dummy objects at unit test time or is there a better way of doing this i.e. mocking out the database? Thanks, Mark. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Think about what value you will really get by testing without the database. You will be testing in a different environment than the code will really run in. You will have to do quite a bit of work to create this fake environment. All to isolate a bit of logic that you can test just as well with the database present. While some advocate this type of isolated unit test, it seems too extreme to me. But then, I find most of my testing is more on the functional scale than unit test anyway, as the logic of a single class without associations seems pretty boring and only in a few cases is worth testing beyond basic functions that are implemented in AR code anyway. The bottom line is do what works for your project, do not be dogmatic about it. Michael On Jun 28, 2007, at 5:55 AM, Mark Gargan wrote:> > While this post is strictly related to ActiveRecord and not Rails > in its > entirety I thought this was probably the best place to ask. If not I > apologise and if someone could point me in the right direction that > would be great. > > I''m putting together a small stand-alone Ruby project (jruby in > fact but > I''m hoping the premise remains the same) > I''ve an alert object which is very straightforward. The <=> method and > to_s methods are overridden but other than > that there''s nothing more to the object as the alerts are inserted > into > the database via a completely seperate java process. > > The problem arises when unit testing. We want to be able to mock > out the > database if possible but because the implementation of the object > is, I > guess, done introspectively against the database table so we''ve no > model > members > to work with and the structure depends on the table. > Should we just forgo the introspective nature of the object and > explicitly map attributes on the Alert object to columns in teh > DB so that we can create dummy objects at unit test time or is there a > better way of doing this i.e. mocking out the database? > > Thanks, > Mark. > > -- > Posted via http://www.ruby-forum.com/. > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk- > unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > For more options, visit this group at http://groups.google.com/ > group/rubyonrails-talk?hl=en > -~----------~----~----~----~------~----~------~--~--- >
Thanks a million for getting back to me Michael, that is indeed a very valid point. Because the project''s implementation alone relies so heavily dependant on their being a db present I guess it''s overkill to go and attempt to implement something just for the sake of tests that will only have to be amended should the db change. Thanks for the perspective. Mark. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jay Fields has talked a lot about this topic. While I agree with the points you''re discussing, I do believe that there are times when you might want to test without the db... one reason might be to speed up the tests. See these posts for more info. http://blog.jayfields.com/2006/06/ruby-on-rails-unit-tests.html http://blog.jayfields.com/2006/09/rubyrails-unit-testing-in-less-than-1.html http://blog.jayfields.com/2007/05/testing-unit-test-of-functional-test.html Just thought I''d chime in :) On 6/28/07, Mark Gargan <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Thanks a million for getting back to me Michael, that is indeed a very > valid point. Because the project''s implementation alone relies so > heavily dependant on their being a db present I guess it''s overkill to > go and attempt to implement something just for the sake of tests that > will only have to be amended should the db change. Thanks for the > perspective. > > Mark. > > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hey Brian. Thanks again for posting those articles. I''ll get stuck into em now. cheers, Mark. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Mark Gargan wrote:> The problem arises when unit testing. We want to be able to mock out the > database if possible but because the implementation of the object is, I > guess, done introspectively against the database table so we''ve no model > members > to work with and the structure depends on the table.> Should we just forgo the introspective nature of the object and > explicitly map attributes on the Alert object to columns in teh > DB so that we can create dummy objects at unit test time or is there a > better way of doing this i.e. mocking out the database?I would write the program so it can run in two modes. In one mode, objects plug into an ActiveRecord db for their data. This gives you fixture support for your tests. In the other mode, objects plug into a wrapper that calls these external services. Either way, you will need Mocha to provide mock-objects in your tests. And your design should obey "Construction Encapsulation", so tests can pass in mock objects without the production code creating its own objects. -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---