CODEWITHSUNDEEP
unit-testingdaodata-access-object
Luca Fülbier
Luca Fülbier

Reputation: 2731

Testing Data Access Objects

When testing a DAO i follow these rules:

This works well for selecting from the database. I setup the database with the data needed for the select, call my DAO and verify, that the returned object has the right values.

But when testing insert, update and delete it gets ugly. I have to write a custom select statement to verify, that the correct data was inserted/updated/deleted in my database. So when im finished writing the tests i could just aswell test my tests again.

Some people on the web suggest mocking literally everything, but that doesn't really test anything imo.

So, how does one test a DAO?

Upvotes: 1

Views: 1247

Answers (2)

O. Sengul
O. Sengul

Reputation: 41

Testing DAO's includes 3 different steps.

1) Testing POJO's (unit tests)

2) Testing DAO's by (integration tests)

3) Testing DAO user classes.

1) Testing POJO's:

This one is quite straightforward and nothing to do with the DAO testing. Mostly done in order to increase the test coverage of a project and usualyy tests the setter and getters of a plain object.

2) Testing DAO's:

This is an integration test and it does not increase the unit test coverage. In this case one has to create and run a test database. Afterthat a test DB session is opened and all the daoMappers are added. Once this setup is done all the methods of the dao class are called and tested one by one.

3) Testing DAO user classes:

In unit test implementations mocking an object is a very useful method. When you are testing a class and this class uses other services, methods and classes; you can easily mock those services, classes and methods since they are probably already tested in some place else. By mocking we mean assuming a specific method returns some specific value or an object.

There are a lot of mocking tools like EasyMock, PowerMockito and PowerMock. In the DAO mocking case (since we had already tested DAO's above, we can mock them) we can mock by using PowerMock.

Upvotes: 2

Alex Marculescu
Alex Marculescu

Reputation: 5770

You don't really have to test DAO, provided they are slim enough (as they should be) and don't contain business logic. You're going to inadvertently test them at some point while writing some system/integration tests for something else.

Depending on what you're using (ORM framework?) you might be able to stub/mock stuff, but it's rarely worth it.

As for using connection strings in NUnit (so to manipulate the DB from your test project), I see nothing wrong with that in general, it's more common than you'd think.

Upvotes: 1

Related Questions