locked
Why not just Mole everything?

    Question

  • Why would I not just want to Mole every class that I need mocked.

    Are Stubs in someway better?  (I can't seem to figure out behaviors yet, so lets leave them out of the running for now.)

    Here are a few scenarios:

    1. If I have a class that needs mocking.  I wrote it but it does not have an interface setup.  What would be the reasoning for adding an interface so I could use Stubs?  Why not just use Moles?
    2. I have a class with an interface, so I could use Stubs, but what do I gain by using Stubs over Moles?  Why not just keep everything with Moles for ease of maintainability?
    Monday, March 22, 2010 8:33 PM

Answers

  • Stubs are definitely faster because vitual method dispatch is supported 'out of the box' by .NET. Moles are slower because they need to rewrite methods, thus jitting is slower and the codegen is worse.

    Moreover, Moles instrument method bodies. If you do not have a body, i.e. interface, abstract methods, they you need to use stubs.


    Jonathan "Peli" de Halleux - Give us your input about Pex!
    • Marked as answer by Vaccanoll Tuesday, March 23, 2010 4:00 PM
    Monday, March 22, 2010 10:42 PM
    Owner
  • As Peli says, Stubs should always be faster. I always try to use the smallest/most simple thing that will work. In this case that is Stubs. The code I work on daily has very few interfaces so I almost always use Moles. Maybe part of your question comes from code that doesn't use interfaces well? In a lot of our code a method may take a instance of an interface as a parameter but it quickly type casts it to a specific class.

    An interesting difference is that if you only use Stubs for a specific test method, you don't have to specify the [HostType("Moles")]. Using the "standard" unit test HostType is noticably faster.

    In the end, what you are trying to test will determine whether you use Stubs or Moles. The only case where this comes up is that you are trying to test a method that takes a instance of your interface as a parameter. You can't hook into the "constructor" of an interface because there is no such thing so you will always have to pass in an already constructed instance. If the instance of your interface is created in the method or the instance is type cast to a specific concrete class (which is bad) then you have to use Moles.

    If you use Moles in the above scenario, you are really testing the concrete instance of the class that implements the interface. The only time I would do that would be if there was significant code in the concrete class that I would have to reimplement in the stub. This, by itself, is a code smell I would consider breaking up the interface of class.

    Just my 2 cents...

    • Marked as answer by Vaccanoll Tuesday, March 23, 2010 4:00 PM
    Monday, March 22, 2010 11:02 PM

All replies

  • The major difference between Moles and Stubs is the technology they build open: Moles use a CLR profiler to rewrite method bodies at runtime, Stubs use virtual method overloading to replace methods. The rule of thumb is if you can get away with Stubs, use them; otherwise use Moles.

    This question asks for an additional section in our moles manual that discusses the pros and cons of both approaches.

     


    Jonathan "Peli" de Halleux - Give us your input about Pex!
    Monday, March 22, 2010 9:03 PM
    Owner
  • Why use Stubs if you can?

     

    Are they faster?  Better in some way?

    Monday, March 22, 2010 9:35 PM
  • Stubs are definitely faster because vitual method dispatch is supported 'out of the box' by .NET. Moles are slower because they need to rewrite methods, thus jitting is slower and the codegen is worse.

    Moreover, Moles instrument method bodies. If you do not have a body, i.e. interface, abstract methods, they you need to use stubs.


    Jonathan "Peli" de Halleux - Give us your input about Pex!
    • Marked as answer by Vaccanoll Tuesday, March 23, 2010 4:00 PM
    Monday, March 22, 2010 10:42 PM
    Owner
  • As Peli says, Stubs should always be faster. I always try to use the smallest/most simple thing that will work. In this case that is Stubs. The code I work on daily has very few interfaces so I almost always use Moles. Maybe part of your question comes from code that doesn't use interfaces well? In a lot of our code a method may take a instance of an interface as a parameter but it quickly type casts it to a specific class.

    An interesting difference is that if you only use Stubs for a specific test method, you don't have to specify the [HostType("Moles")]. Using the "standard" unit test HostType is noticably faster.

    In the end, what you are trying to test will determine whether you use Stubs or Moles. The only case where this comes up is that you are trying to test a method that takes a instance of your interface as a parameter. You can't hook into the "constructor" of an interface because there is no such thing so you will always have to pass in an already constructed instance. If the instance of your interface is created in the method or the instance is type cast to a specific concrete class (which is bad) then you have to use Moles.

    If you use Moles in the above scenario, you are really testing the concrete instance of the class that implements the interface. The only time I would do that would be if there was significant code in the concrete class that I would have to reimplement in the stub. This, by itself, is a code smell I would consider breaking up the interface of class.

    Just my 2 cents...

    • Marked as answer by Vaccanoll Tuesday, March 23, 2010 4:00 PM
    Monday, March 22, 2010 11:02 PM