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.
on 2007-06-28 14:55
on 2007-06-28 17:31
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 2007-06-28 17:39
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.
on 2007-06-28 18:59
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-un... http://blog.jayfields.com/2006/09/rubyrails-unit-t... http://blog.jayfields.com/2007/05/testing-unit-tes... Just thought I'd chime in :)
on 2007-06-28 21:08
Hey Brian. Thanks again for posting those articles. I'll get stuck into em now. cheers, Mark.
on 2007-07-02 00:52