Say you have a class A that depends on B and C. You can either inject B and C into A and mock them during testing, or you can factor out the methods inside A that use B and C, and mock those methods during testing. This second choice could be more useful when dealing with legacy code. Any opinions?
As an example, say A is some service class and B is a database connection. B is used once inside A, doing a query. Factor out method useBToGetObject() and mock it might be easier than mock the database connection, especially if the usage is complicated (building a query or whatever).
useBToGetObject()
But then you are not fully testing the unit (A in this case). It really depends on your testing objectives, but I would not do this.
Well, maybe A is not the unit I’m interested in, but rather A->theMethodToTest()?
When people do unit testing they start equating classes with units. Units can be one class, but can be a unit (heh…) of cohesive classes acting as one component.
Those weird scenarios where you mock databases and try to patch your way through a test may suggest your unit boundary is too granular, and your units not well defined. Think about what the unit is in your code.
Also in general mocking databases is futile, it’s better to just load test data in there and use live DB for testing, and then be able to mock the entire stateful unit with in-RAM test version for your other units that use it (i.e. segregate the unit touching the DB from the rest, don’t let the DB go around all your code).