Atleast in context of typical CRUD APIs, a set of functional tests that run against an in-memory database like H2, are far more realistic and practical in catch

Atleast in context of typical CRUD APIs, a set of functional tests that run against an in-memory database like H2, are far more realistic and practical in catching issues while being very fast. My typical approach for such scenarios is to define, for every test: a) the base data, b) inputs to the service wrapper method (that is typically invoked via the handling method upon REST call (e.g. in case of a POST request, the body DTO) and c) the post-change expected state - all as JSON test assets. Then before every test, I can load the base data at the start of the tests, call the method with payload DTO, extract the final database state and compare that with expected result state (changes are rolled back at end of each test so they are isolated). I don't need to care about what the nested services/methods are doing as long as the expected state matches. This approach has helped me catch issues time and again and I would pick this over unit tests for typical CRUD APIs. One scenario where I would prefer unit tests is computation focused methods that would benefit from thorough testing using a wide variety of input values.