Test::Unit mocking the db

Rails
1

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.

2

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

3

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.

4

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.

Just thought I’d chime in :slight_smile:

5

Mark G. 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
Test Driven Ajax (on Rails) [Book]
“Test Driven Ajax (on Rails)”
assert_xpath, assert_javascript, & assert_ajax

6

Hey Brian.

Thanks again for posting those articles. I’ll get stuck into em now.

cheers,
Mark.