none
Code Contracts for .NET 4.0 question RRS feed

  • Question

  • Hi there

    I'm considering the "NUnit -> Code Contracts migration" for my new projects. Upon reading documentation I came to conclusion that, comparatively to Unit Testing, the latter approach tests my code while it runs (or while I develope it). The Units Testing works as a separate project and condacts all checkings/validation on my side, not on the client's. I can run all tests overnight and have it done by the morning with no client side involving.

    Is it the case case that I cannot do this scenario with Code Contracts? Do all problem/violations manifest itself primarily when the software is working on the client side?

    Thanks

    Monday, August 18, 2014 12:49 PM

Answers

  • Hi Renziglov,

    This forum is for questions about Visual C#, your question is actually off-topic. I recommend you open up a new thread in the dedicated Code Contracts forum for better support:

    http://social.msdn.microsoft.com/Forums/en-US/home?forum=codecontracts

    Thanks for your understanding.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    • Edited by CaillenModerator Tuesday, August 19, 2014 3:33 AM
    • Marked as answer by Renziglov Tuesday, August 19, 2014 12:36 PM
    Tuesday, August 19, 2014 3:33 AM
    Moderator
  • Caillen

    Thanks for advice. I removed the thread for re-openening it in another location you recommended.

    • Marked as answer by Renziglov Tuesday, August 19, 2014 12:36 PM
    Tuesday, August 19, 2014 12:35 PM

All replies

  • Edit:

    I think I answered the wrong question but I'll leave this guff here just in case someone else reads the thread

    ----------------------------------

    I recommend you look at bdd and specflow.

    TDD is very fine grained usually and the time invested is rarely repaid.

    BDD is a more input >processing > output orientated and can be implemented quicker.

    Having said that you can go fine or coarse grained with either.

    I find the way you lay out your data in "tables" much more intuitive with specflow.

    .

    You need to write your applications with testing in mind.

    That means you want to use mvc, mvvm or mvp.

    Separate out your code "does things" from the markup/code which presents it and the code which provides the data.

    The ability to run fast tests in seconds in visual studio after each iteration is invaluable.

    You cannot do this if you test via the UI so you need dumb(ish) ui.

    You also cannot run that fast with a dependency on a database so you need to be able to inject a mock database.

    You can refactor ( relatively ) safely, work in a team much more safely and generally make changes while being confident you didn't break something way over there in the back of your application which you didn't realise was dependent on your change.

    It requires a bit of a different approach and you need to break things up and convert lots of stuff to implementing interfaces so you can inject mocks and stubs at test time.

     At first this seems like a waste of time but once you get past that you start to notice it encourages better structure of your code.

    .

    TDD is not a panacea.

    There is no substitute for a human being tester.

    They look at your app and ask those awkward questions you never really thought about when you wrote the thing.

    What happens if the user does this....

    Why the F do you have to go through three sceens between this commonly used bit of the syatem and that commonly used bit of the system?

    That kind of thing a tester can do and a computer can't.

    You also possibly want "slow" tests run overnight on a server as part of continuous integration if you have a big team.



    Hope that helps
    Please don't forget to up vote answers you like or which help you and mark one(s) which answer your question.



    Monday, August 18, 2014 1:32 PM
    Moderator
  • Hey Andy

    My projects are already test-centric, hence it has been built with the BDD in mind. I'm talking about the migration from Unit Testing to Code Contracts for new projects.

    I do not like that, with Unit Testing, I have to switch to a Testing project and add the test portion while I'm concentrating on the business implementation. The Code Contracts aloows me doing it exactly at the same place and at the same time. First I write contracts, second I implement logic for the same scope and here we go.

    But! See my concern on Code Contracts above again.

    Thanks.

    Monday, August 18, 2014 1:46 PM
  • Hi Renziglov,

    This forum is for questions about Visual C#, your question is actually off-topic. I recommend you open up a new thread in the dedicated Code Contracts forum for better support:

    http://social.msdn.microsoft.com/Forums/en-US/home?forum=codecontracts

    Thanks for your understanding.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    • Edited by CaillenModerator Tuesday, August 19, 2014 3:33 AM
    • Marked as answer by Renziglov Tuesday, August 19, 2014 12:36 PM
    Tuesday, August 19, 2014 3:33 AM
    Moderator
  • Hello,

    Well, there are few things to note here and I'll break it down into multiple paragraphs.

    What is Unit Testing? you can hear different people say different things but all agree that unit testing is a kind of test that the programmer writes to assert that the assumptions he makes about the behaviour of a unit under test or system under test (SUT) matches her expectations.

    Now, there are two camps here.

    Pessimistic/Purist: Contracts are not part of your test suit.

    Before CodeContracts, Design by Contract (DbC) was enforced by testing the arguments of the functions but assertions on the other hand are never tested because a) they removed on release builds. b) during development you use them in conjunction to Unit Testing so it doesn't make sense to test them. c) they are not really meant to be testable.

    A purist person does not treat contracts as if they were asserts and she will most likely use either one of the following approaches to verify that the arguments are validated correctly.

    a) She will create tests around contracts and probably throw specific exceptions either through legacy exceptions or using Contract.Requires<TException>(...).

    b) She will use Contract.Requires(...) and then verify that the generic exception is thrown or use the Contract.ContractFailed event.

    Either way using CodeContracts like this becomes a great burden both in development time, performance and maintainability.

    Optimistic: Contracts are part of your test suit.

    An optimistic person will treat contracts as if they were assert statements and won't bother test them at all and she will most likely use Contract.Requires(...).

    Now, a very important thing about Unit Testing is that it can't verify whether you programmed something correctly it can only verify whether the result you get is the same result you expected so if you think about a precondition/postcondition of a function or a class and you explicitly say that something cannot go below zero and then you have the static analyzer that proves this assumption for you why would you bother having a test around it?

    Some people will answer this by saying it prevents someone else from breaking the code by somehow eliminating this condition and maybe have regression but then the static analyzer can tell you that it's violated and trust me it does much better job than having a unit test around your arguments validation.

    Others will answer this by saying that the static analyzer can be disabled but then again you can delete tests and the nice thing about the tooling in CodeContracts is that once it's enabled you can see what was violated and fix it.

    So to summarize, the precondition/postcondition of CodeContracts are like assert statements, the static analyzer uses them to prove/disprove the assumptions so it does exactly the same job as a test runner which is to run tests and then tell you whether they passed but here you don't have to write the actual tests, they are embedded in the code itself.

    I tend to treat contracts like asserts so I remove them on release builds but in most cases I'll still keep them on my public APIs for arguments validation, it depends on the library/application.

    P.S. Let me just clarify something.

    TDD and BDD are both a software development methodologies and you can use them anytime you do testing not just Unit Tests as well as you can use them together or apart but they share nothing with this topic, really.

    Regards, Eyal Shilony

    Tuesday, August 19, 2014 3:35 AM
    Moderator
  • Caillen

    Thanks for advice. I removed the thread for re-openening it in another location you recommended.

    • Marked as answer by Renziglov Tuesday, August 19, 2014 12:36 PM
    Tuesday, August 19, 2014 12:35 PM