1

When testing a DAO i follow these rules:

  • Use an in-memory database
  • Reset database data for every test

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?

Xstian
  • 8,184
  • 10
  • 42
  • 72
Luca Fülbier
  • 2,641
  • 1
  • 26
  • 43

2 Answers2

2

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.

O. Sengul
  • 41
  • 3
1

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.

Alexandru Marculescu
  • 5,569
  • 6
  • 34
  • 50
  • Thank you for the answer, but i didn't quite get the last part. What is a connection string in NUnit and how does it relate to this problem? – Luca Fülbier Jul 06 '16 at 09:13
  • You're right, I haven't been as clear as I could've, because I don't know what language/framework you're testing in (C#/Java?). You mentioned you're reseting the database data for (before/after?) every test - you're probably doing that by connecting to the DB directly from your test project, which is fine. – Alexandru Marculescu Jul 06 '16 at 09:20
  • I understand. I actually have no specific language/framework. I was asking for a general approach. – Luca Fülbier Jul 06 '16 at 09:27