an alternative approach that I used to work a lot with is to encapsulate your data fetching logic in dedicated repository beans. Just give the functionality:
dataManager.load(Customer.class).query("select e from example_Customer e where e.name = :lastName").parameter("lastName", lastName).view("myView").optional()
a dedicated place to live like
CustomerRepository with a method:
Optional<Customer> findCustomerByLastName(String lastName).
This way you don’t have to mock a fluent interface (like the API of
DataManager) as this is normally quite problematic to do. Instead, you mock the method call to your repository, which is way easier, as it has a simpler API in terms of mocking.
It also gives you the additional benefit that you don’t mix up your business logic with database interaction logic.
I wrote an article about that topic in CBUA a while ago: Don’t squash your business logic.
For the split of integration tests and unit tests, you can still decide to do positive tests as integration tests and negative tests as unit tests. But it also adds another option:
- write only unit tests against your business logic with the mocking of your repository
- write only integration tests for the database interaction logic
Normally the nature of database interaction logic is to work with the DB. Mocking the DB makes little sense there. But for all the business logic, you don’t really care if it is correctly persisted - as long as you know that it gets transmitted correctly to the repository class. This is why mocking makes very much sense here.