Smocks
Smocks copied to clipboard
Support for generic method mocking
I've always had issues with generic methods when using smock for mocking. This solved some of it. Granted not done the most elegant of ways. Would love your ideas for further improvements.
Hello, thanks for the pull request. I will review it in more detail later.
For every fix, there should be unit tests that fail before the fix was added and are successful afterwards. Can you please add unit tests that illustrate the problem(s) that the fix resolves?
@vanderkleij we faced problems with generic methods where generic method is in different project to the caller of the generic method. For ex:
Project A
class WithGeneric{
string some<T> (T key){
//code goes here.
}
}
Project B-Unit test
class Tester{
public void TestGenericCallToAnotherProject(){
Smock.Run(context =>
{
string expected = "shouldReturn";
context.Setup( () => It.IsAny<WithGeneric>().some("someString")).Returns(expected);
string actual = new WithGeneric().some("someString");
Assert.AreEqual( expected, actual);
//This assertion will fail because some<T> is not getting mocked and we checked by debugging that call is going inside the actual implementation of the some<T> method.
});
}
}
NOTE: If you try by placing unit test and the class to be tested (here WithGeneric) in same project it works fine.
Also, we took the code changes that are made by @feng3245, his changes actually made the code work. So I request you to please to accept the changes of his commits.
Will resolve conflicts and re-issue pull request
@vanderkleij I have also checked that when you mock overloaded methods (I don't know exactly that it is the case with generic methods that are placed in same or different projects) it's not able to mock them and control went to the actual method. Please look into this issue also. Thanks.
@feng3245 Just fork this repo. It looks like this feature will never be merged.
@feng3245 Just fork this repo. It looks like this feature will never be merged.
Someone already created a beta extension out of this check point. Frankly this project is kind of doomed with the coming .NET Core as it is removing the secondary app domain that this the library heavily depends on. The only work around for this is to write everything that have even any remote amount of static method calls in .NET Standard and reference them to tests under .NET4.6.1 or under. It is a royal pain.