mocking mscrolib

Generally mscorlib stuff won't work, though precisely why that's the case is not something I can speak to. I'd guess it's because Typemock Isolator itself is a .NET library and if you were mocking things you needed to use... well, I could see how that could get problematic.

I played around with mocking Console.WriteLine, and while I can mock the call - so nothing gets written to the console - I see that the FailWhenCalled expectation generates a slightly misleading message. It doesn't have anything to do with the Console.WriteLine so much as the test framework I'm using having attached to the console output:

Demo.Class1.MyTest : TypeMock.VerifyException :
TypeMock Verification: Unexpected Call to NUnit.Core.EventListenerTextWriter.
WriteLine()
at TypeMock.MockManager.a(String A_0, String A_1, Object A_2, Object A_3, Boolean A_4, Object[] A_5)
at TypeMock.InternalMockManager.getReturn(Object that, String typeName, String methodName, Object methodParameters, Boolean isInjected, Object p1)
at NUnit.Core.EventListenerTextWriter.WriteLine(String aString)
at System.IO.TextWriter.SyncTextWriter.WriteLine(String value)
at System.Console.WriteLine(String value)

Of course, technically it IS failing when the method is called, so you're getting what you want... even if the error message is a little misleading.

A simple workaround to make things cleaner around this would be to do a slight redesign so you have a "Log" method that does all of the logging in your class and have the Console.WriteLine in there. Then you could fail when your "Log" method is called rather than failing when Console.WriteLine is called.

The TypeMock folks sometimes are able to chime in with a feature that's already there but you never knew existed - maybe they'll have some additonal info here.

1) We tallked about the exception that is thrown - In my tests it was thrown when using the FailWhenCalled() call,
now I understand a little bit about what happens... dotnet calls dotnet ...

2) I didn't understand your exception - which look differnec then mine, please post your code and where the exception was thrown.

3) about the Log (I called it wrapper) -> I don't like it cause I can do it also with Rhino for free...

Thanks...

I used your test code, but chances are you're seeing a slightly different exception for one of two reasons:

1) I'm using test decorator attributes to verify my mocks and you're not. Sometimes the exception looks a little different. Just above the test fixture class, I have [VerifyMocks]:

[TestFixture]
[VerifyMocks]
public class MyTests{
...
}

2) I'm running my tests in the NUnit GUI, so you see the NUnit.Core.EventListenerTextWriter in the exception. If I was running in TestDriven.NET, I believe you'd see a TestDriven.EventListenerTextWriter reference in there. (I don't recall the exact type off the top of my head, sorry.)

As for whether or not you like abstracting away your calls to Console.WriteLine, that's a design decision you'll need to make. If you'r worried about the API clutter, you make it private and still be able to mock it with TypeMock - something I don't believe you can do in Rhino. But again, the design for your class is entirely your call.

Thanks Tillig.
Just a short explanation:

You can easily mock Console.WriteLine() by redirecting the output (use Console.SetOut)

It is also possible to mock the Methods of the redirected class - this is what is happening with NUnit. The Console is redirected to an NUnit class which is then mocked automatically via Typemock.