0

Given this class:

public class MyClass 
{  
     private void MyMethod()  
     {  
         //...
     }  

     public void Execute()
     {  
        try
        {
             //...  
             MyMethod();  
             //... 
        }  
        catch(Exception e)  
        {  
            ...  
        }   
     }  
}

How can I Mock MyMethod to throw an OutOfmemoryException ?

EDIT 1:

Given the next situation where MyMethod loads some data from database, and some unpredicted error occurs, MyMethod will throw an exception. I want to be able to unit test that situation. In my case the catch clause from execute method.

Rey
  • 3,663
  • 3
  • 32
  • 55
radu florescu
  • 4,315
  • 10
  • 60
  • 92

4 Answers4

6

I don't use Moq, so it's possible that there's some way you can do it - but I'd argue that if you need to, you're doing mocking wrong.

You should usually be mocking dependencies - and you can't be depending on their private members from the class you're trying to test, can you? Typically I'd mock an interface - occasionally it can be useful to mock a class, but I typically don't. If you're calling into some dependency and you want the result of that call to be an OutOfMemoryException, just make that public call throw the exception.

If you feel you've got a good reason to want to mock a private method, please give more details about your context.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    Actually no - there are good reasons to mock private methods in unit tests sometimes. – TomTom Jan 13 '12 at 14:39
  • @TomTom: Can't say I've ever come across them - just asserting this isn't terribly helpful... can you give an example? – Jon Skeet Jan 13 '12 at 14:41
  • SImple - you test implementation details of a class. OR internal access code that you dont want normal users to be able to easily replace. This mostly comes up less in application and more in API design where you dont want the user to ahve too amny ways to shoot himself into the foot, but still need to be able to unit test your classes. – TomTom Jan 13 '12 at 14:43
  • 2
    @TomTom: If I'm testing the implementation details of a class, I don't mock *that class*. Note that I specifically talked about *private* methods. I have no problem with the idea of mocking *internal* methods which are part of a dependency relationship. If you'd said there are good reasons to mock *internal* methods, I'd have agreed - at the very least internal virtual methods of abstract classes. – Jon Skeet Jan 13 '12 at 14:47
3

You can only mock public properties and public methods (regardless if defined in an interface or in class directly).

Fischermaen
  • 12,238
  • 2
  • 39
  • 56
  • 1
    @TomTom: Do you have a bit more information than "Actually not correct."? – Fischermaen Jan 13 '12 at 14:40
  • @TomTom please give an answer, regarding you comments with the correct version. – radu florescu Jan 13 '12 at 14:41
  • Simple - it is a problem of low quality / "standard" mocking frameowrks. THere are some that allow you to replace even static methods. – TomTom Jan 13 '12 at 14:43
  • 1
    @TomTom: OP has tagged his question with "moq" and I don't know any way to mock private methods with moq. So my answer was to his question. – Fischermaen Jan 13 '12 at 14:45
  • 1
    @TomTom: I fail to see how you can reasonably say this answer is incorrect, yet give an answer which ends with: "So, sorry, there is no way to do that with Mock." (I think you mean Moq, rather than Mock, but...) – Jon Skeet Jan 13 '12 at 14:49
  • `Protected()` lets you set expectations for protected members using the member name as a string. – TrueWill Jan 14 '12 at 01:45
-1

What you run into is basically a limitation of the primitive waqy Mock works for mocking.

There are some commercial frameworks out there that work around that - JustMock from Telerik being the most reasonable priced one. They work by attaching themselves as profilers and replacing the bytecode executed - so they really MOCK the methods.

MOCK - and all others excelpt a handfull - work by basically subclassing / implementing and you can not subclass a private or non virtual method. THat makes them useless to mock any properly defined sealed object that should not be subclassable - you have to program your objects open which then allows all kinds of possible abuse.

They also can not mock static methocs- which the few ones can. This is very usefull because it allows you for example to Mock a call to DateTime.UtcNow so it always returns a SPECIFIC time, which may be needed in a unit test.

So, sorry, there is no way to do that with Mock.

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • Please provide some links to read more about what you mentioned here. Thanks – radu florescu Jan 13 '12 at 14:43
  • Ah - http://www.google.com/. Telerik is the company. JustMock the name of the product I use. – TomTom Jan 13 '12 at 14:44
  • 3
    You say "primitive" - I say "appropriate for mocking *dependencies*". – Jon Skeet Jan 13 '12 at 14:58
  • 1
    (You might also want to mention [TypeMock Isolator](http://www.typemock.com/isolator-product-page-d).) – Jon Skeet Jan 13 '12 at 14:59
  • No, at 2500 USD per machien - including build agent systems - i consider it to be ridiculously overpriced. TypeMock is 400 per developer - build systemsa are free. – TomTom Jan 13 '12 at 15:16
  • -1. Every open source framework I know of has the same limitations as Moq. While the commercial frameworks have value, particularly when testing legacy code, Moq works quite well for testing well-designed classes. This is generally done by mocking injected interfaces, which are not affected by the sealed/unsealed debate. – TrueWill Jan 14 '12 at 01:40
  • Thanks. Yo uare fired for incompetence. Depending what you do even in modern code sealing your code is fundamental. But then, siome people only make websites, or? – TomTom Jan 14 '12 at 05:42
-1

I've not had a chance to try this, but we use Moq some where I work and I've been struggling with stuff like this as well. First off, Moq is not based off of public, private, etc. per se. It is based on what your test class has visibility into. We're doing a lot with VB.net so my recent memory is colored by that (ie take this with a grain of salt). 1) In order to test "private" methods--Try to make your test assembly have visibility into the assembly that contains your classes under test. Look here for information on how to do this. You will need to change them to "internal" (same as friend in vb.net). In classic TDD you (generally) try to have everything in your class under test visibile to the test itself. 2)Once you have visibility into the MyMethod, you should be able to mock out a response of any kind of exception that you need (presuming you can instantiate and throw it). 3) Other ideas are to create an internal class in your test code that extends the class under test and override the method that you want to control from inside your test class.

Sometimes, especially with legacy code, you have to do some ugly things to make the code testable.

John Dahle
  • 244
  • 1
  • 6