0

Just a basic question I hope is within the rules to ask. I have been looking for some information from some experience "Automated Testers" who have practiced this before. What is the business functionality of mocking static IEnumerable methods? Is there anything that is attained from mocking them? Does it just create clutter code/tests? How would someone know that it is worth writing a test for one of the IEnumerable methods? I have read up on the ways to accomplish the task of mocking and testing just curious what purpose it serves. Wouldn't system methods work just fine and not need to be tested?

Please excuse my questions if they are "green" I am just trying to get a deeper understanding/knowledge base of testing.

Eric
  • 699
  • 5
  • 15
  • Are you talking about the Linq extension methods (`Where`, `Select`, `OrderBy`, etc.)? I certainly see no reason to mock those out, and AFAIK you can't mock static functions with RhinoMocks anyway (c.f. http://stackoverflow.com/questions/540239/mocking-static-methods-using-rhino-mocks), even if you wanted to. – Magnus Grindal Bakken Sep 03 '13 at 17:43
  • I am and that is what I figured, I just didn't have any "experienced/senior" input to back it up and nail it in my head. Also there is a way to mock static functions I thought - http://stackoverflow.com/questions/540239/mocking-static-methods-using-rhino-mocks?answertab=oldest#tab-top How would I know what IEnumerable methods to mock? Currently have partial code coverage on the Linq extendion methods (I believe). I would be more than happy to provide more details if you would be able to provide more answers. I am new so I am trying to expand my knowledge base around automated testing. – Eric Sep 03 '13 at 17:51
  • The accepted answer on the post you linked to (which is the same one I linked to) says pretty clearly that RhinoMocks can't mock static functions. TypeMock can do it, and Microsoft's own Fakes framework can do it, but RhinoMocks can't. – Magnus Grindal Bakken Sep 03 '13 at 17:54
  • Roger. However this workaround was stated also "Wrap the static method call in a virtual instance method in another class, then mock that out" what is stopping me from practicing that? Again I apologize if my questions might come off junior and seem frustrating. Just looking to understand. – Eric Sep 03 '13 at 17:56
  • 1
    Don't sweat it! Nothing is stopping you from creating wrappers for Linq extension methods and then mocking those out, but there's really not much point. The idea behind mocking is to isolate the code you're testing, so problems in other functions/classes/modules don't indirectly cause test failures in your own code. That's a good idea in general, but sometimes you just have to trust that the code you're depending on is working correctly, and Linq is one of those cases. Wrapping Linq calls just to mock them out would be a big honking waste of time, in my opinion. – Magnus Grindal Bakken Sep 03 '13 at 18:04
  • 1
    Also, in response to this: "Currently have partial code coverage on the Linq extendion methods (I believe)." - Your job is to test *your own* code, not other people's code. Microsoft (probably) have unit tests of their own for their Linq extension methods, since they're the ones who wrote them. You should concentrate on writing tests that test the code that *you* have written. – Magnus Grindal Bakken Sep 03 '13 at 18:06
  • This was my original post/thread that I started that lead me down the path I am currently on. http://stackoverflow.com/questions/18520653/partial-code-coverage-c-sharp-nunit/18521891?noredirect=1#comment27373025_18521891 Any input? I marked it as answered because I figured I had come to the resolution. However just curious if another set of eyes would be able to see what isn't being "Covered"? – Eric Sep 03 '13 at 18:34

1 Answers1

0

There is no business functionality to mocking the system IEnumerable methods. To Mock static methods however, you should create a virtual class that calls the static methods. You then mock the virtual class allowing yourself to "access" the static methods in test.

Eric
  • 699
  • 5
  • 15