chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
Hello, the following code used to work:

var fakeCommand = Isolate.Fake.Instance<SqlCommand>(Members.ReturnRecursiveFakes);
Isolate.Swap.NextInstance<SqlCommand>().With(fakeCommand);
Isolate.WhenCalled(() => fakeCommand.ExecuteReader(0)).WillThrow(Isolate.Fake.Instance<SqlException>(Members.ReturnRecursiveFakes));

However, after upgrading to TypeMock 5.2 it throws the following exception:

TypeMock.TypeMockException :
*** Cannot use WhenCalled without a complementing behavior statement

I tried to split the last statement into two:

var fakeCommand = Isolate.Fake.Instance<SqlCommand>(Members.ReturnRecursiveFakes);
Isolate.Swap.NextInstance<SqlCommand>().With(fakeCommand);
var ex = Isolate.Fake.Instance<SqlException>(Members.ReturnRecursiveFakes);
Isolate.WhenCalled(() => fakeCommand.ExecuteReader(0)).WillThrow(ex);

Now I get:
TypeMock.TypeMockException :
*** Cannot mock methods defined in types from mscorlib assembly.

What I can see now that I can't mock SqlException:
Isolate.Fake.Instance<SqlException>();

And result is the same "cannot mock mscorlib" exception from TypeMock.

What should I do to handle this? It used to work prior 5.2 release.

Thanks in advance.
asked by vagif (19.4k points)

6 Answers

0 votes
Hi Vagif,

We have an issue that was introduced when we added "True Properties" feature.
Unfortunately while using Recursive Fakes accidentally caused a faking of a property that has implementation inside MsCorLib.

The solution is quite simple - use Members to set a different behavior for example:
 var exception = Isolate.Fake.Instance<SqlException>(Members.CallOriginal);
            Isolate.WhenCalled(() => fakeCommand.ExecuteReader(0)).WillThrow(exception); 


We have another issue in the test - when the test host finish running DbConnection.Finalize is called. This issue only happens in MSTest

I suggest you use MustSpecifyReturnValues, CallOriginal or ReturnNulls when creating SqlCommand.

We are working of fixes for both bugs at the moment
answered by dhelper (11.9k points)
0 votes
Hi,

Unfortunately this does not solve the issue. The problem is with faking SqlException: it just can't be faked when using anything else than recursive fakes. Using "Call original" results in other failure, and if I use "Returns null" behavior, I get "Cannot mock methods defined in types from mscorlib assembly". So I used recursive fakes for good reason: that was the only way to simulate SqlException thrown by SqlDataReader.
answered by vagif (19.4k points)
0 votes
Strange - I was able to Fake SqlException using CallOriginal

I will send you a patch to solve this issue later today
answered by dhelper (11.9k points)
0 votes
It is possible to fake SqlException using CallOriginal but the problem may arise later depending on where SqlExcetion is thrown. In my case I do the following:
- fake SqlException
- set the expectation on SqlCommand.ExecuteReader
- run the test code that will eventually reach ExecuteReader call.

What happens is that deep in that code (or I should say somewhere in System.Data.SqlClient code) certain properties of SqlException ar accesses, and this causes failure I get.
answered by vagif (19.4k points)
0 votes
I'll send you a patch that enables Faking of SqlException.

BTW
This patch will be part of our next version
answered by dhelper (11.9k points)
0 votes
It works with the patch you sent me. Thanks a lot!
answered by vagif (19.4k points)
...