Should I use DAOs from production code to setup & verify tests?

Question

I'm currently working on a project that consists of multiple repositories all having a dependency to the repository which stores code for database manipulation:

• repo1 for AWS lambda1 having databaseRepo as a dependency
• repo2 for AWS lambda2 having databaseRepo as a dependency
• repo3 for AWS lambda3 having databaseRepo as a dependency
• ...
• databaseRepo - SQL scripts, Repositories & DAOs (with plain JDBC ) for database manipulation.

We have MySQL in production and in memory H2 for testing purposes. Lets assume that I want to test logic in one of the repositories (eg. repo1) that requires some records in database in order to return success. We need to insert a row before test executes and we also assert if other row was properly modified at the end of the test. Which approach is better/cleaner for test setup and verification?

1. Using repositories/DAOs from databaseRepo ( production code ) in order to perform CRUD operations within test.
2. Creating test code for DAO/repository layer and use it across tests code only.

Currently we are using second approach which IMHO is better in our case , as we do not have databaseRepo logic well tested. However, this way we have a little bit of code duplication and we need to maintain more code.

Which approach are You using and why?

Regards, Michal

Answer 1

Cześć Michał! :) If I understood you correctly I would also go for second option. You are testing code/module that has external dependency to repository data. So you may abstract this dependency to an interface and create two implementations: one for production and one for test. In my opinion this is clean, despite it has a bit of code duplication.

Other thing you can do is to even use mocks to tell declaratively what values you expect to drive your tests.

Hope this helps. :)