Base class
Especially in older codebases, services and components can be part of a deep hierarchy of classes. Often, belonging to a class hierarchy makes it so a class inherits requirements and behaviors from its ancestors.
Each mock offers properties and constructor overloads to accommodate these requirements, such as constructor arguments, and retain the needed behaviors.
For this section, the following class will be used
public class Person
{
public Person(string name)
{
Name = name ?? throw new ArgumentNullException(nameof(name));
}
public string Name { get; }
public virtual void Greet() => TestContext.Progress.Writeline($"Hello, I'm {Name}.");
}
Please notice that the method
Greet is defined as virtual, thus allowing subclasses to redefine its behavior.Generally, when mocking interfaces, there is no need to specify constructor arguments since the mock is backed by a class created with a parameterless constructor.
Unfortunately, this might not be the case when mocking classes.
In this case, developers can specify the constructor arguments when creating the mock.
var mock = new Mock<Person>("John");
The snippet above will create a mock backed by a class inheriting from
Person even if it requires a string in its constructor.Sometimes the classes to be mocked present one or more virtual methods whose default implementation already satisfies the needs of the mock. In cases like this it makes sense to preserve the original behavior, rather than let Moq override the method.
Moq offers two ways to achieve this.
The first one is by configuring each method accordingly by using the CallBase construct.
mock.Setup(p => p.Greet()).CallBase();
Alternatively, developers can instruct Moq to always resort to the base class behavior, whenever there is one.
var mock = new Mock<Person> { CallBase = true };
This approach is particularly useful when members of the base class are not publicly visible.
Last modified 2yr ago