Mocking frameworks are a great utility to alleviate some of the pressure of testing in a large project. They are especially useful when trying to wrap tests around a legacy system. A legacy system, in this case, is defined as an application that does not already have tests around it. This definition is from Michael Feather's book, Working Effectively with Legacy Code.

Use caution while learning Test-Driven Development and using mocking frameworks. Mocking frameworks provide a very attractive alternative to carefully considering your code. It is possible to write a complete set of tests that, in the end, only really test the mocking framework.

Many mocking frameworks are overpowered in this respect. In C#, a classification of mocking frameworks exists that allows you to replace external code. This external code includes DateTime.Now and any other class that you don’t control. In JavaScript, this is called monkey patching, and every framework allows you to do it.

What's the harm, you ask? One of the benefits of TDD is that it encourages smart architectural choices. When you have the power to override the functionality of the third-party code, you no longer have the need to abstract in order to test.

Why is that a problem? Abstraction of the third-party is necessary if we want to keep the code flexible and if we want to follow the SOLID principles.