Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Has anyone ever written DBD::MockDB

by stvn (Monsignor)
on Apr 06, 2004 at 20:11 UTC ( #343102=perlquestion: print w/replies, xml ) Need Help??
stvn has asked for the wisdom of the Perl Monks concerning the following question:

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!


Replies are listed 'Best First'.
Re: Has anyone ever written DBD::MockDB
by jZed (Prior) on Apr 06, 2004 at 20:43 UTC
    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?

Re: Has anyone ever written DBD::MockDB
by dragonchild (Archbishop) on Apr 06, 2004 at 20:17 UTC
    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?

    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Re: Has anyone ever written DBD::MockDB
by lachoy (Parson) on Apr 07, 2004 at 00:48 UTC
    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...)

    M-x auto-bs-mode


      This is exactly what I am looking for. Funny that I think I probably tried every Mock* combination on 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.

Re: Has anyone ever written DBD::MockDB
by belg4mit (Prior) on Apr 06, 2004 at 20:29 UTC
    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

    I'm not belgian but I play one on TV.

Re: Has anyone ever written DBD::MockDB
by jfroebe (Parson) on Apr 06, 2004 at 21:07 UTC
    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


    No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Re: Has anyone ever written DBD::MockDB
by waswas-fng (Curate) on Apr 06, 2004 at 22:55 UTC
    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. =)


      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 and in particular the FAQ are great introductions to the idea behind Mock objects.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://343102]
Approved by kvale
Front-paged by broquaint
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2017-06-25 18:11 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (568 votes). Check out past polls.