0

What is the best way to Mock a return type if we don't care about the actual state of the object.

For example, I am Mocking a method whose return type is: IEnumerable<Document>

Now, I can add relevant Nuget package and add necessary namespace so the type Document is defined, however I actually don't need to test anything on the returned object and I feel it's an overkill to include the Nuget and add namespace.

What other alternatives are available instead of including the reference?

|improve this question
  • 1
    IEnumerable<IDocument> , Document is a concrete type, if you don't care about document abstract it away. – Jon Raynor Nov 28 '18 at 20:46
  • If you're mocking something with Document, it means the code under test is using Document, which means you already need the nuget/reference because you're referencing something that depends on it. No? – Telastyn Nov 28 '18 at 21:10
  • @Telastyn Yes, for now I have opted to include it. Was wondering if there was an alternative way. – Shamim Hafiz Nov 28 '18 at 21:18
4

If you don't care about the state the method returns in unit test, this is a code-smell. You need to reevaluate the design of this method as it is likely doing too many things at once.

The a method should generally return void if it alters the state of its owning object. This is not a hard rule, but if what it is returning is complicated enough to need to be mocked, then I'd guess your method is not one of the exceptions to the rule.

Methods should generally either alter state, or return data, but not both. Refactor this method into two separate methods.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.