1

I have this method in ContractClass:

  public UserModel GetUser(string groupName, string login) {
     Contract.Requires(groupName != null);
     Contract.Requires(groupName != string.Empty);
     Contract.Requires(login != null);
     Contract.Requires(login != string.Empty);

     return default(UserModel);
  }

How would you test this? Do you test all combinations of all possible scenarios when contract fails (ex: groupName is empty and login is null ... and so on)?

Vladimir Nani
  • 2,774
  • 6
  • 31
  • 52
  • `String.IsNullOrWhitespace(value)` or `String.IsNullOrEmpty(value)` – Davin Tryon Dec 27 '13 at 09:21
  • Aren't contracts removed from release build? Do you run your tests against non-release build? – zerkms Dec 27 '13 at 09:23
  • 1
    If you mean all possible permutations, I fail to see the point in that. After all, the checks on each parameters are independent of each other here. It would quickly become unmanageable if you add more parameters too. – Thorarin Dec 27 '13 at 09:27
  • Since I am not a C# devel, to me it would seem that the best option would be to mock the `Requires()` method, because to write a proper unit test, you have to isolate said unit. Then again, this entire method looks like made of pure global state. – tereško Dec 27 '13 at 10:43
  • @zerkms Yes they are removed but i am runing tests while being still in `Debug` mode. – Vladimir Nani Dec 29 '13 at 18:24

2 Answers2

2

Yes, otherwise

  • you have not tested all possible faults,
  • and you have dependencies in your tests.

E.g.: If you only test that it fails when groupName is equal to null and login is equal to null, and your test fails - you can not be sure that it fails for the correct condition. And what's even more important: You can not even be sure that you have all the correct and important calls to Contract.Requires.

Golo Roden
  • 140,679
  • 96
  • 298
  • 425
  • 2
    `You can not even be sure that you have all the correct and important requires.` how would you be so sure about this? All you can do, at this point, is `string.IsNullOrWhiteSpace`. A failing precondition is a sign of a bug in **calling** side. When you fail your preconditions in unit tests, you basically have shown, that there is a bug (intended) in your tests. Note that, Design by Contract is different from defensive coding. – Ilya Ivanov Dec 27 '13 at 09:22
2

I wouldn't write any unit tests for those Code Contracts at all. If your preconditions are wrong, then peer code review is a better way of picking that up. If your preconditions are correct, then all you'll end up testing is that the Code Contract engine works, not that your code works.

It might be worth running integration tests to check that your preconditions are not too strict, but in most cases the output of the static verifier will be a better guide.

If a precondition becomes particularly complex, then there's an argument for unit testing it. However, in that instance, I'd be tempted to extract the precondition into a [Pure] method, and unit test that instead.

Stephen J. Anderson
  • 436
  • 3
  • 6