Warning, the following code example is suitable for a narrow range of use cases\u2026 but it\u2019s strangely useful.<\/p>\n
When writing tests against Spring services or controllers, we may wish to mock the DAO layer completely. This can be achieved:<\/p>\n
@MockBean\nprivate MyDao myDao;<\/pre>\nAnd the mock dao is then wired into our services etc.<\/p>\n
However, there are situations where we\u2019re doing something complex in a higher order test, and we want this DAO to function just enough. This is where the following function may help:<\/p>\n
\/**\n * Turn any integer keyed mock dao into a sort of working one for save and findById\n *\n * @param mockDao the dao to mock\n * @param <T> the type of element\n *\/\nstatic <T> void givenFakeSaveAndLoad(CrudRepository<T, Integer> mockDao,\n Function<T, Integer> getId, BiConsumer<T, Integer> setId) {\n Map<Integer, T> fakeDb = new HashMap<>();\n AtomicInteger idGenerator = new AtomicInteger(123);\n given(mockDao.save(any()))\n .willAnswer(answer((T toSave) -> {\n if (getId.apply(toSave) == null) {\n setId.accept(toSave, idGenerator.getAndIncrement());\n }\n fakeDb.put(getId.apply(toSave), toSave);\n return toSave;\n }));\n\n willAnswer(answer((Integer id) -> Optional.ofNullable(fakeDb.get(id))))\n .given(mockDao)\n .findById(argThat(id -> id >= 123));\n}<\/pre>\nWhat this is doing is simulating a really simple database by using a
Map<\/code>. It can operate on anyCrudRepository<\/code> where the key field is anInteger<\/code>. Technically you could make it operate on other key types if you wanted to. I\u2019m usingAtomicInteger<\/code> as the key generator here, soInteger<\/code> is all I want.<\/div> <\/div><\/p>\nWhat this code does is puts a POJO in a
Map<\/code> on save and retrieves it from theMap<\/code> onfindById<\/code>. There are many ways this is not enough of a mock of a database\u2026 but let\u2019s just look at an example of using it:<\/p>\ngivenFakeSaveAndLoad(learnerDriverDao,\n LearnerDriver::getId,\n LearnerDriver::setId);<\/pre>\nWe call it with the DAO we wish to mock and the functions on the POJO that access its ID field. Then it adds this moderately handy map-based DAO.<\/p>\n
Why It\u2019s Rubbish<\/h2>\n
Loads of reasons why this is not a good idea:<\/p>\n
\n
- The POJO stored in the
Map<\/code> is mutable, so any code that modifies it will affect the database\u2019s<\/em> copy.<\/li>\n- DAOs have many more methods than
save<\/code> andfindById<\/code> and this doesn\u2019t cover them<\/li>\n- Tests that rely on stateful mock objects soon get out of hand<\/li>\n<\/ul>\n
Conversely, this is a simple pattern that\u2019s really helped make a few tests easy!<\/p>\n
\n