Imagine a "DatabaseManager" class which job is, well, manage a database schema. If you need to create a mock of an "IDatabaseAdapterFactory" (and I use the term "mock" liberally) that returns a mock of an "IDatabaseAdapter" to test the manager, chances are big that you are testing implementation details. It's even worse if the subject-under-test also needs mocks of other dependencies. In this particular example, I'd prefer to actually include...
...the actual database using a SQL Server/Linux container or SqlLocalDB and drop the mocks altogether. In other situations, applying the Dependency Inversion Principle and an adapter to bridge your new and clean contract with the ugly dependencies can really help.