I’m having a simple test design problem, which I would like to solve once and for all.
I’m pretty used to regular Java design pattern where there is some Manager interface (or facade) and a set of DAO interfaces. Concrete implementation of ManagerImpl is using concrete implementations of DaoImpl.
Right now I’m at the point of implementation, where I don’t have a database connected to my project yet, so I guess this is a perfect time to write proper unit tests without DB 🙂
I was able to mock some methods of my manager by using mockito, but since the Test Under Method (or so called System Under Test) is using DAO internally, I would have to mock the DAO as well. Unfortunately I cannot do that without setting concrete DAO implementation in my manager, like myManager.setMyDao(mockedDao), but now I would have to pull out this setMyDao method into interface, which of course breaks encapsulation and makes my clean and perfect interfaces look like garbage.
So the question is: How to mock DAO in tests while preserving clean Manager-Dao architecture?
You should unit test concrete implementations, i.e.
ManagerImplTest, which will explicitly createManagerImpland therefore you have allsetMyDaomethods available for mocks. Your test will not know aboutManager interface.BTW, it is not always necessary to create interfaces for everything. In most cases only single implementation of managers and daos will exist. If there is no any other strong reason (e.g. Spring AOP proxies or dependency separations), I guess it’s better don’t create interfaces for everything in sake of simplicity.