Has anyone ever written DBD::MockDB

[stvn]

I recently was looking at Test::MockObject as a means of faking a database in a test suite I am currently working on. But then it occured to me, what about a mock DBI driver. I looked around on CPAN, but could not find anything of the sort (at least not with the search terms I was using), I even poked around Google, but everything was coming up Java. So i decided I should give it a whirl myself. I have downloaded DBD::Template as well as DBD::FIle (the "default" driver supplied with DBI), and started digging through them. But before I go to far, I thought I would ask the monastary to see if I am re-inventing the wheel here already.

Has anyone either done this, or heard of someone doing this? Or ever tried to do this before and failed/gave up for whatever reason? Also I would invite comment on the idea itself, any thoughts on what it should be able to do, etc, etc. I am only really in the researching stage so far, so I am open to any ideas.

Update To Clarify
The idea is not so much to do tests on a file or memory based DB, but to be able to interact transparently with DBI and have the Driver be able to validate the tests in a way. In particular in cases of dynamically generated SQL, as opposed to straight DBI interaction.

Another Update
lachoy wrote DBD::Mock, which is exactly what I was looking for (pays to ask before you jump in I guess). I have been using it all day today with much success, I recommend it to other who might have similar needs. Excellent job lachoy!

-stvn

[jZed]

DBI now (version 1.42 and higher) comes with a very simple but usable database that does not require any other installation other than core Perl and the DBI distribution itself - DBD::DBM. It is built on top of DBD::File and DBI::SQL::Nano, now both also in the DBI distribution. So DBD::DBM is an option if your goal is to be able to create, populate, modify, and query a simple database with DBI and SQL but without requiring any other installations.

If your goal is test without complicating IO issues, you can use DBD::AnyData (the successor of DBD::RAM) in RAM-storage mode which will allow you to do DBI/SQL operations on in-memory databases without any file IO.

If there are other things you are wanting that these don't accomplish, can you be more specific about what you'd want to support?

[dragonchild]

You could use something like DBD::SQLite or DBD::CSV, couldn't you? I mean, if you're database actions, you want to make sure things are happening correctly, right?

[lachoy]

Actually, I recently wrote DBD::Mock, which may be appropriate for what you want. (And if you're interested in working on it drop me a line...)

[stvn]

Chris,

This is exactly what I am looking for. Funny that I think I probably tried every Mock* combination on http://search.cpan.org i could come up with except Mock itself. I guess i was overthinking that one.

I will let you know how it works for me. I am actually interested in working on it, although it seems you have implemented alot of it already. I will drop you a line once i take a closer look.

-stvn

[belg4mit]

In EZDBI t/02connect.t I try to use any of the semi-standard unrestricted access drivers such as: Sprite, SQLite, WTSprite, XBase. There's also DBD::RAM

[jfroebe]

Hi Steven,


While I can see the use of a DBD::MockDB... I have a hard time determining if it would be worth the effort.

Specifically because the various DBMS can be wildly different (GDBM, Sybase ASE, Oracle, Poet ODBMS, Postgres, etc.). Often you will find that you have to code queries and even algorythms specially coded for your desired DBMS. Simple dbms client applications can usually get away with DBMS neutral coding but if you are talking about enterprise-class applications, you usually end up choosing a DBMS and sticking with it, unfortunately.

If you were simply talking about testing your code with a bare bones "get a record", "write a record", then I would go for the suggestions the others have mentioned (GDBM, DBM, xBase, etc.)

hope this helps

Jason

[waswas-fng]

I guess I am missing the point, wouldn't testing the actual functionality of the DB backend and data integrity via the used DBI/DBD and in source SQL be the goal of the DBI related test harness for your application? Doesn't using a fake DB remove one of the possible fail points that actually exists in the application that uses DBI? =) How about a module that replaces your app's subs with print's that output what your harness expects -- seems like another way to simplify your tests. =)

[stvn]

The idea is two fold:

1. It is sometimes very difficult to get a real database to act in all the ways you want to test against without having to jump through hoops. For instance, with a mock DB object, testing how your app will perform when the DB connection goes down can be automated by making the mock DB object mimic that. To replicate this in reality and automate it would be difficult at best.
2. Mock objects do not test the actions of the objects they are mocking (the DB in this case) but the objects which use it. So in my particular instance I want to test my objects that use the database, but I really dont care about the database, as that is not (in this case) relevant to the test itself.
This site http://www.mockobjects.com and in particular the FAQ are great introductions to the idea behind Mock objects.
-stvn