Good unit tests help you design code that is easy to use. They do that by being a little tedious to write. Remember, the test is where the code learns to play nice with others.
So if the code under test requires a lot of magic to be verified, it will not be straightforward to use in the codebase.
A rule of thumb is to favour testing frameworks that are so simple that you could easily just have written the code yourself. A testing framework is a convenience. It should not make it possible to test things that you could not test before.
When you need to construct the test data, write your test doubles and create every other dependency needed, pure laziness will create code that is modular and easy for others to use. This is the design pressure from the tests.
If you let a framework entangle your code, unit testing gets hard really fast. A Wunderbaum testing framework will mock and stub your controllers and databases, instead of helping you keep the domain logic separate and testable. It removes the design pressure, one of the reasons to write tests first.
Sometimes you end up with a codebase that needs to get under test before it can be fixed. Often that can be done through approval testing or end-to-end testing, just to have some sense of safety. In that process you might also find Wunderbaum testing frameworks helpful, since the code stinks so much you need all the perfume you can get.
But when the code just has some odour, try to avoid things that hide the smell. If your code is hard to test with a slim testing framework, you probably have code that is too interdependent, or not modular enough.
Keep your code nose fresh and think of design pressure as a friend.