patterncsharpMinor
Mocking the class under test with private method calls
Viewed 0 times
callsmockingthemethodwithprivateundertestclass
Problem
Consider the scenario below. It covers multiple methods of my unit under test.
However, in my production code there is a lot that I need to Mock away that is then used in more method calls. I need to find a way to test the
I came up with the scenario as below. However the disadvantage is that i need a interface and pass the instance in each method. I do not like this design.
Any feedback?
```
public interface INewSample
{
bool Foo(ISomeEntity entity, INewSample sample);
bool Bar(ISomeEntity entity);
}
public class NewSample : INewSample
{
public bool Foo(ISomeEntity entity, INewSample sample)
{
return entity.IsThatSo ? entity.IsThatSo : sample.Bar(entity);
}
public bool Bar(ISomeEntity entity)
{
return entity.IsThatAsWell;
}
}
[TestClass]
public class NewSampleTest
{
[TestMethod]
public void Foo_EntityWithSo_ReturnsTrue
{
// Arrange
Mock someEntityMock = new Mock();
mock.SetupGet(m => m.IsThatSo).Returns( false );
Mock sampleMock = new Mock();
sampleMock.Setup(m => m.Bar).Returns(false).Verify();
// Act
private bool result = _OriginalSample.Foo( someEntityMock.Object, sampleMock.Object );
// Assert (that the log
public class OriginalSample
{
public bool Foo(ISomeEntity entity)
{
return entity.IsThatSo ? entity.IsThatSo : Bar(entity);
}
public bool Bar(ISomeEntity entity)
{
return entity.IsThatAsWell;
}
}
[TestClass]
public class OriginalSampleTest
{
[TestMethod]
public void Foo_EntityWithSo_ReturnsTrue
{
// Arrange
Mock someEntityMock = new Mock();
mock.SetupGet(m => m.IsThatSo).Returns( false );
mock.SetupGet(m => m.IsThatAsWell).Returns( true );
// Act
private bool result = _OriginalSample.Foo( someEntityMock.Object );
// Assert
Assert.IsTrue(result);
}
}However, in my production code there is a lot that I need to Mock away that is then used in more method calls. I need to find a way to test the
Foo method without hitting the Bar method.I came up with the scenario as below. However the disadvantage is that i need a interface and pass the instance in each method. I do not like this design.
Any feedback?
```
public interface INewSample
{
bool Foo(ISomeEntity entity, INewSample sample);
bool Bar(ISomeEntity entity);
}
public class NewSample : INewSample
{
public bool Foo(ISomeEntity entity, INewSample sample)
{
return entity.IsThatSo ? entity.IsThatSo : sample.Bar(entity);
}
public bool Bar(ISomeEntity entity)
{
return entity.IsThatAsWell;
}
}
[TestClass]
public class NewSampleTest
{
[TestMethod]
public void Foo_EntityWithSo_ReturnsTrue
{
// Arrange
Mock someEntityMock = new Mock();
mock.SetupGet(m => m.IsThatSo).Returns( false );
Mock sampleMock = new Mock();
sampleMock.Setup(m => m.Bar).Returns(false).Verify();
// Act
private bool result = _OriginalSample.Foo( someEntityMock.Object, sampleMock.Object );
// Assert (that the log
Solution
You can't.
You need to ask yourself why it is you want to prevent executing Bar during testing. If it is because you are worried about over-covering Bar during testing, stop worrying. If it is because your real Bar implementation is long-running, then you probably need to inject another dependency into your class, or re-factor some code into a separate helper class which can then be injected.
As long as your Foo implementation needs to call Bar, your unit tests for Foo ultimately need to as well. As long as Foo ultimately calls Bar, you cannot fully test Foo without executing Bar. You shouldn't rely on it calling Bar, but you cannot prevent it from calling Bar in your tests without intentionally crippling your test coverage.
You need to ask yourself why it is you want to prevent executing Bar during testing. If it is because you are worried about over-covering Bar during testing, stop worrying. If it is because your real Bar implementation is long-running, then you probably need to inject another dependency into your class, or re-factor some code into a separate helper class which can then be injected.
As long as your Foo implementation needs to call Bar, your unit tests for Foo ultimately need to as well. As long as Foo ultimately calls Bar, you cannot fully test Foo without executing Bar. You shouldn't rely on it calling Bar, but you cannot prevent it from calling Bar in your tests without intentionally crippling your test coverage.
Context
StackExchange Code Review Q#11995, answer score: 4
Revisions (0)
No revisions yet.