-
-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for code contracts #94
Comments
See this pull request for a quick implementation that adds basic compatibility with Code Contracts. |
Does this build on SL or do we have conditionals in place? |
Code Contracts should be fully support on the Silverlight platform. It compiles. |
This doesn't compile or work on v3.5. I'm reverting this change until that's figured out. Thanks. |
It would seem that since Moq no longer targets .NET 3.5 at all, that roadblock would be out of the way. First, let me admit that while I've played around with Code Contracts it a few times over the years, I am not deeply familiar with it. That being said, I fail to see how sprinkling a few As far as I understand it, The once possible option I can see is to factor out the contract blocks into separate contract classes ( Finally, and this is perhaps the final nail in the coffin, according to microsoft/CodeContracts#409 ("What does the Future of Code Contracts Look Like?"), development on Code Contracts has more or less ceased and it apparently isn't supported on .NET Core. I will happily stand corrected if I have misunderstood anything in this issue or in the PR referred above (#95). Until that happens, I don't see how adding Code Contracts contract blocks would benefit Moq or its consumers, so I'm closing this issue for the time being. |
At the moment, Moq offers no support for Code Contracts, which is included in C# 4.0.
While we can disable code contracts on test assemblies, contracts often provide very useful information about the external facing requirements of our libraries, so this is a less-than-ideal solution.
The workaround to this is to include intermediary assumptions about the library. This is highly verbose, and completely clutters up any tests using code contracts.
For anything that requires a non-null object by contract, we would need to explicitly specify an assumption about the output of the Moq library. This requires a huge amount of extra intermediary code, at least one assumption for every mock.
The best alternative is to include code contract information in the Moq library itself, which would provide clear guarantees as to the preconditions and postconditions of the Moq API.
It's worth noting that this is likely worth doing in and of itself as code contracts can add a great degree of robustness to an existing library.
The text was updated successfully, but these errors were encountered: