As others have stated in this topic, your DB access should be encapsulated behind some interface, e.g., MyDatabaseService or MyDAO (DAO = Data Access Object). The methods in your app that access the DB will do so through this interface, and as such can be mocked/stubbed (I recommend EasyMock for this). If you DI (dependency injection, a.k.a. IOC, inversion of control), changing your methods to use the mock/stub instead of the real DB-accessing implementation of MyDatabaseService is easy (I recommend Spring for the DI).
When unit testing the implementation of MyDatabaseService itself, use an in-memory DB, e.g., HSQLDB. There is no reason unit tests should ever access a stateful DB; this is what integration tests are for. If you cannot write unit tests without accessing an external resource like a DB, you need to refactor your app code.
DI and the practice of dividing your app up into modules/services that all have generic interfaces is a wonderful enabler of proper "pure" unit testing. Go to Spring's website for examples of these practices.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
45464748495051
|
»
]
Previous Topic
