Also some fun takeaways: it also makes external calls to azure to load configuration and stays silent after updating for 2 weeks before showing warnings.
Moq is unusable. Needs to be forked or repoaced. Time to switch to NSubstitute.
Also some fun takeaways: it also makes external calls to azure to load configuration and stays silent after updating for 2 weeks before showing warnings.
Moq is unusable. Needs to be forked or repoaced. Time to switch to NSubstitute.
If your usage is that ingrained, the other option is to fork it and drop the dependency, or swap to any of the already-numerous forks that do so. Unless there’s licensing concerns with that approach?
You’re relying on the fork to remain maintained, or else you risk you run into build/functional issues at some undetermined point in the future when it becomes incompatible with other changes in your environment/project. If you don’t trust the fork will be maintained, you should begin decoupling your project from the library anyway. I would be more willing to trust an alternate (or no) mocking framework over a Moq fork to be supported in the long term. That might change in a couple months if one becomes established.
I would personally wait a couple months, or until the original Moq creator reverses course. (If he does that, I think it’s unlikely a fork will compete with the original, so I’d start removing the dependency as I can’t trust the author anymore.)