views:

280

answers:

6

I have a class which has a internal method and i want to mock the internal method . But i am unable to mock it i.e. it is not calling the mocked function but calling the original function. Is there any way to achieve this ?

Edit:Actually i am a novice to the Moq. I have many classes and methods of the classes to test using the Moq. Many classes are internal , many have internal methods, many have not-virtual methods . And can not change the signature on the methods and classes. Can anyone please let me know how to go about testing this scenario using Moq. Or else please suggest me some other testing framework which is easy to learn and easy to work with .

+6  A: 

Why would you want to mock an internal method?

If you find the need to mock an internal method, say to sidestep a dependency or an interaction, you perhaps should consider redesign of the class.

Inversion of Control and Dependency Injection are some possible design strategies that can reduce coupling and increase cohesion of your classes and eliminate the need to mock internal methods.

I don't believe there is a clear path to non-public mocking with Moq.

But, if you absolutely must, you can use TypeMock Isolator to mock just about anything.

Also, just so it doesn't get lost in the din: Thomas linked a good article on using the free MS Moles to mock non-public members.

Mocking the Unmockable: Using Microsoft Moles with Gallio

Sky Sanders
Indeed, mocking private methods is typical code smell.
mikek
I strongly disagree: If you do TDD, then mocking internal stuff is a regular, everyday thing...
Thomas Weller
@Thomas - I understand your perspective. But you must realize that the classical strategy is defined as testing a classes behavior, typically by interface, rather than it's internal implementation as this tightly couples your tests to the internal implementation and induces inertia and breakage when refactoring. I would have to say that you are in the minority with your opinion. note: i have read a bit of your blog and know that you are quite thoughtful and TDD is dear to you - I just disagree with your disagreement. ;-)
Sky Sanders
@Poet: Agreed, if you do a behavior-based strategy then testing only against the public interface of course makes sense. What I meant was: There can be other strategies, which require testing internal stuff, and this is not necessarily a bad thing. - Maybe a minority thing, but not somehow erronous. It also makes perfect sense within its context... No need to discuss about that, I think... ;-).
Thomas Weller
+1  A: 

Unit testing should test the interface of a class. You can mock out dependencies, but implementation details of the class itself (such as private methods) should be tested as part of the whole class, not separately, and not changed for the test (otherwise you would be testing a different unit then would really be used).

If you feel it is necessary to change the method to make the class testable, refactor the class so that the difficult part becomes a dependency, or otherwise substitutable by parameter or subclassing.

Thilo
What if you develop your code test-first, in baby-steps? You will regularly need to deal with internal code one way or the other...
Thomas Weller
+4  A: 

Not with Moq.

But you can use the free Moles framework from MS to do such things. I wrote about it here: Mocking the Unmockable: Using Microsoft Moles with Gallio. (it applies not only to Gallio, but it gives a good overall impression of what you can do with Moles...). The other alternative would be Typemock...

HTH. Thomas

Thomas Weller
+ for the writeup on free tools
Sky Sanders
A: 

If you need to test lots of code that you can't change, you should better go with MS Moles or TypeMock from the beginning.

Free mocking frameworks like Moq give you only support on interfaces and virtual methods anyway. Does not sound as if you will go far with that...

Thomas

Thomas Weller
A: 

You can easily mock a internal virtual methods by adding the following to your AssemblyInfo.cs:

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")] // namespace in Moq
[assembly: InternalsVisibleTo("YourTestClass")]

I'm not a unit testing expert, but I don't understand why other answers are saying you should never do it? Isn't that what you do when you use the 'Extract and Override' (local factory method) dependency injection technique outlined by Roy Osherove in Chapter 3 of The Art Of Unit Testing?

Daryn
A: 

Mark the method as internal *protected* (also virtual of course)

andreister