# Test::Unit mocking the db

**URL:** <https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027>\
**Category:** Rails\
**Created:** [June 28, 2007, 2:55pm UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027 "2007-06-28T14:55:44Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![bowenmark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@bowenmark](https://www.ruby-forum.com/u/bowenmark)\
**Post date:** [June 28, 2007, 2:55pm UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027/1 "2007-06-28T14:55:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bowenmark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@bowenmark](https://www.ruby-forum.com/u/bowenmark)\
**Post date:** [June 28, 2007, 5:31pm UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027/2 "2007-06-28T17:31:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bowenmark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@bowenmark](https://www.ruby-forum.com/u/bowenmark)\
**Post date:** [June 28, 2007, 5:39pm UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027/3 "2007-06-28T17:39:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bowenmark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@bowenmark](https://www.ruby-forum.com/u/bowenmark)\
**Post date:** [June 28, 2007, 6:59pm UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027/4 "2007-06-28T18:59:58Z")

</div>

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.

> **[Ruby on Rails Unit Tests](http://blog.jayfields.com/2006/06/ruby-on-rails-unit-tests.html)**
>
> Updated following multiple comments requesting examples and questions on where to put AR::Base subclass tests. Everyone (who reads this blog...

> **[Ruby/Rails Unit Testing in less than 1 second](http://blog.jayfields.com/2006/09/rubyrails-unit-testing-in-less-than-1.html)**
>
> I previously wrote about removing the database dependency from Ruby on Rails Unit Tests . I'm pleased to say that several months later my t...

> **[Testing: Unit Test or Functional Test](http://blog.jayfields.com/2007/05/testing-unit-test-of-functional-test.html)**
>
> Update at bottom. A common question when adding a new class is: Do I need a Unit test or Functional test? The answer: Yes. I'm not sure why,...

Just thought I’d chime in 🙂

---

<div class="post-metadata">

**Author:** ![bowenmark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@bowenmark](https://www.ruby-forum.com/u/bowenmark)\
**Post date:** [July 2, 2007, 12:52am UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027/5 "2007-07-02T00:52:27Z")

</div>

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]](http://www.oreilly.com/catalog/9780596510657/)  
“Test Driven Ajax (on Rails)”  
assert\_xpath, assert\_javascript, & assert\_ajax

---

<div class="post-metadata">

**Author:** ![bowenmark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@bowenmark](https://www.ruby-forum.com/u/bowenmark)\
**Post date:** [June 28, 2007, 9:08pm UTC](https://www.ruby-forum.com/t/test-unit-mocking-the-db/108027/6 "2007-06-28T21:08:35Z")

</div>

Hey Brian.

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

cheers,  
Mark.