I think I see what you're trying to do here, but it won't work with Mocks, because even if you do create a Mock SomeClass
, you also have to mock the SomeMethod
function - you can't use the real one!
That means that you are not testing it, just testing the mocked version of it.
However, why not try this without Mocks?
You can make SomeOtherMethod
virtual, and then subclass SomeClass
just for this test.
You then write whatever override of the SomeOtherMethod
function you like; when you call the real SomeClass.SomeMethod
, it will call into that overridden version.
i.e. (sorry, doing this in C# as my VB is rusty) suppose SomeClass
looks like this, picking a deliberately useless functionality so as not to confuse:
public class SomeClass
{
public virtual int SomeMethod()
{
return SomeOtherMethod() / 2;
}
protected virtual SomeOtherMethod()
{
return [some crazy maths]
}
}
You want to test that SomeMethod
correctly returns half of what SomeOtherMethod
does.
So now you can do this, in the test project:
public class SomeClassTestDouble: SomeClass
{
protected override int SomeOtherMethod()
{
return 2;
}
}
then in your test:
var sut = new SomeClassTestDouble();
var expected = 1;
var actual = sut.SomeMethod();
Assert.Equal(expected, actual)
Now you have tested that SomeMethod
works as expected without any Mocking. Indeed many would argue that, unless you are crossing an architectural or system boundary, you prefer test doubles (which includes stubs) over Mocks. I'm not going to say if I agree or not in general, but in this case I think it's better not to Mock.
Note on the Attributes
Bear in mind re. the Attributes - they should not do anything at all until some other part of the system tells them to do something. If that part of the system is not running (i.e during tests) then these attributes should be totally inert. If they are not, then I'd tend to look at your Unit Test project and make sure you're not accidentally running "live" stuff like runtime security frameworks or something