单元测试数据库交互器

Question

I have a database interaction component which has, amongst other things, a Writer and a Reader class. The writer class has write methods such as insertEntity( Entity ) and updateEntity( Entity ), while the Reader has methods such as getEntityById( EntityId ).

For implementing this component I'd like to use TDD as I usually do, though am unsure on how to manage this. If I start with implementing the Writer, how am I going to do meaningful asserts if I do not have the Reader methods yet. And even if I had the Reader methods, I'd preferably not want to use them in the tests for the Writer, though perhaps this is wishful thinking.

Testing such code seems inherently a pain as tables need to be setup and teared down. However since I have not tried to do TDD for such code before, I might be missing out on tricks to make this relatively painless. Any pointers on that are appreciated.

Answer 1

You don't need a database for this as long as you have an abstraction in place.

For example if I made a method getEntityById , I could have a class which would use an in memory store (array, hash etc...). While my production code would make use of a concrete instance. In pseudo code:

class MemoryStore
{
    getEntityById(id)
    {
       // Return hardcoded response or canned results
    }
}

class DatabaseStore
{
    getEntityById
    {
        // Go off to the real database and do reads.
    }
}

You can then write you tests without ever hitting a real database. Remember, if you do consume a third party service, API, DB, file system etc... you are not unit testing.

The other benefit here is that you can have another developer working on the database access code, while you work on the rest of the application. This all relies on "coding to an interface".

What if you want to test the database access code? Well you would want an integrated test. A real database would be used here and you can instantiate the code which read/writes to the database. Naturally this would be slow and require seed data. The point is you test these standalone, the rest of you app would use the in memory fakes. So in the above example, as long as the DatabaseStore worked on its own, we could be confident the rest of the code did the right thing.

Answer 2

What I do is implement my CREATE methods first and I test these by querying the database directly and not through my DAO's READ methods. When these pass you can write your READ tests using your CREATE methods to populate your database with test data and then implement your READ methods.

As far as setting up and tearing down the database after each test, place the SQL to do this in your set-up and teardown methods.