tag:blogger.com,1999:blog-581522584150589505.post7295830024755388094..comments2024-01-08T10:09:19.311+01:00Comments on Techie things: NUnit and Microsoft Contracts libraryAnonymoushttp://www.blogger.com/profile/06980674445694201967noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-581522584150589505.post-80452139385063277542009-12-20T16:41:02.927+01:002009-12-20T16:41:02.927+01:00Thanks Manuel, you are right!
The solution above i...Thanks Manuel, you are right!<br />The solution above is just a quick and dirty workaround.Anonymoushttps://www.blogger.com/profile/06980674445694201967noreply@blogger.comtag:blogger.com,1999:blog-581522584150589505.post-7154917584225461382009-12-18T17:50:47.073+01:002009-12-18T17:50:47.073+01:00If you want your tests to exercise actual contract...If you want your tests to exercise actual contract failures, you have to be extremely careful in how you decide if your test succeeds or fails. What you suggest above will also make the test succeed if the contract failure is not the one you expect, but a real failure in the test case.<br />To handle the above scenario, you would want to customize the runtime contract behavior as described in sectin 7.7 of the documentation. This way, you can throw e.g., your own exception and in the catch handler of the test, compare the expected to fail condition string. This way, you make sure that the failure is the expected one.<br />In general, testing for failing contracts is not recommended, just like you are not writing test cases that will make your "asserts" fail.Manuel Fahndrichhttp://research.microsoft.com/contractsnoreply@blogger.com