I always assumed the point of mocking a database response was to ensure that you were testing just your code, and not also the existence of a database with the right schema, the ability to connect to it, as well as the correctness of the code that rolls back any side effects.
I like testing those things on which my model depends. It gives me much more confidence. Why wouldn't I want to test them?
Those things all need to be tested, but if a single unit test fails, it's nice to know that it failed because the code was wrong, not because the database connection happened to die just then. If I have one test for the logic, and another that verifies that the database can be connected to, and a third that verifies the schema is right, then the specific combination of failing tests tells me a lot more about what's wrong and if my code even needs to be changed.
Comments
I always assumed the point of mocking a database response was to ensure that you were testing just your code, and not also the existence of a database with the right schema, the ability to connect to it, as well as the correctness of the code that rolls back any side effects.
I like testing those things on which my model depends. It gives me much more confidence. Why wouldn't I want to test them?
That's a drawback. No arguments from me on that one.
Those things all need to be tested, but if a single unit test fails, it's nice to know that it failed because the code was wrong, not because the database connection happened to die just then. If I have one test for the logic, and another that verifies that the database can be connected to, and a third that verifies the schema is right, then the specific combination of failing tests tells me a lot more about what's wrong and if my code even needs to be changed.