几年前我写过这个，但不太详细。这是同一想法的更精致的版本。
单元测试对开发人员来说既是福也是祸。它们允许快速测试功能、可读的使用示例、快速实验所涉及组件的场景。但它们也可能变得混乱，需要在每次代码更改时进行维护和更新，并且如果懒惰地完成，则无法隐藏错误而不是揭示错误。
我认为单元测试如此困难的原因是它与测试相关，而不是代码编写，而且单元测试的编写方式与我们编写的大多数其他代码相反。
在这篇文章中，我将为您提供一种编写单元测试的简单模式，该模式将增强所有好处，同时消除与正常代码的大部分认知失调。单元测试将保持可读性和灵活性，同时减少重复代码并且不添加额外的依赖项。
但首先，让我们定义一个好的单元测试套件。
要正确测试一个类，必须以某种方式编写它。在这篇文章中，我们将介绍使用构造函数注入进行依赖项的类，这是我推荐的进行依赖项注入的方法。
然后，为了测试它，我们需要：
但这说起来容易做起来难，因为它还意味着：
谁喜欢这个？
解决方案是使用构建器软件模式在 Arrange-Act-Assert 结构中创建流畅、灵活且可读的测试，同时将设置代码封装在一个类中，以补充特定服务的单元测试套件。我称之为 MockManager 模式。
让我们从一个简单的例子开始：
// the tested class
public class Calculator
{
private readonly ITokenParser tokenParser;
private readonly IMathOperationFactory operationFactory;
private readonly ICache cache;
private readonly ILogger logger;
public Calculator(
ITokenParser tokenParser,
IMathOperationFactory operationFactory,
ICache cache,
ILogger logger)
{
this.tokenParser = tokenParser;
this.operationFactory = operationFactory;
this.cache = cache;
this.logger = logger;
}
public int Calculate(string input)
{
var result = cache.Get(input);
if (result.HasValue)
{
logger.LogInformation("from cache");
return result.Value;
}
var tokens = tokenParser.Parse(input);
IOperation operation = null;
foreach(var token in tokens)
{
if (operation is null)
{
operation = operationFactory.GetOperation(token.OperationType);
continue;
}
if (result is null)
{
result = token.Value;
continue;
}
else
{
if (result is null)
{
throw new InvalidOperationException("Could not calculate result");
}
result = operation.Execute(result.Value, token.Value);
operation = null;
}
}
cache.Set(input, result.Value);
logger.LogInformation("from operation");
return result.Value;
}
}
这是一个计算器，按照传统。它接收一个字符串并返回一个整数值。它还缓存特定输入的结果，并记录一些内容。实际操作由 IMathOperationFactory 抽象，输入字符串由 ITokenParser 转换为标记。别担心，这不是一个真正的课程，只是一个例子。让我们看一个“传统”测试：
[TestMethod]
public void Calculate_AdditionWorks()
{
// Arrange
var tokenParserMock = new Mock<ITokenParser>();
tokenParserMock
.Setup(m => m.Parse(It.IsAny<string>()))
.Returns(
new List<CalculatorToken> {
CalculatorToken.Addition, CalculatorToken.From(1), CalculatorToken.From(1)
}
);
var mathOperationFactoryMock = new Mock<IMathOperationFactory>();
var operationMock = new Mock<IOperation>();
operationMock
.Setup(m => m.Execute(1, 1))
.Returns(2);
mathOperationFactoryMock
.Setup(m => m.GetOperation(OperationType.Add))
.Returns(operationMock.Object);
var cacheMock = new Mock<ICache>();
var loggerMock = new Mock<ILogger>();
var service = new Calculator(
tokenParserMock.Object,
mathOperationFactoryMock.Object,
cacheMock.Object,
loggerMock.Object);
// Act
service.Calculate("");
//Assert
mathOperationFactoryMock
.Verify(m => m.GetOperation(OperationType.Add), Times.Once);
operationMock
.Verify(m => m.Execute(1, 1), Times.Once);
}
让我们稍微打开一下它。例如，即使我们实际上并不关心记录器或缓存，我们也必须为每个构造函数依赖项声明一个模拟。在操作工厂的情况下，我们还必须设置一个返回另一个模拟的模拟方法。
在这个特定的测试中，我们主要编写了设置、一行 Act 和两行 Assert。此外，如果我们想测试缓存在类中的工作原理，我们必须复制粘贴整个内容，然后更改我们设置缓存模拟的方式。
还有一些负面测试需要考虑。我见过许多负面测试做了类似的事情：“设置应该失败的内容。测试它失败”，这引入了很多问题，主要是因为它可能会因完全不同的原因而失败，并且大多数时候这些测试遵循类的内部实现而不是其要求。正确的阴性测试实际上是完全阳性的测试，只有一个错误的条件。为了简单起见，这里的情况并非如此。
所以，言归正传，这里是相同的测试，但使用了 MockManager：
[TestMethod]
public void Calculate_AdditionWorks_MockManager()
{
// Arrange
var mockManager = new CalculatorMockManager()
.WithParsedTokens(new List<CalculatorToken> {
CalculatorToken.Addition, CalculatorToken.From(1), CalculatorToken.From(1)
})
.WithOperation(OperationType.Add, 1, 1, 2);
var service = mockManager.GetService();
// Act
service.Calculate("");
//Assert
mockManager
.VerifyOperationExecute(OperationType.Add, 1, 1, Times.Once);
}
拆包，没有提到缓存或记录器，因为我们不需要在那里进行任何设置。一切都已打包且可读。复制粘贴此内容并更改一些参数或某些行不再难看。 Arrange 中执行了三种方法，一种在 Act 中执行，一种在 Assert 中执行。仅抽象了实质的模拟细节：这里没有提及 Moq 框架。事实上，无论决定使用哪种模拟框架，此测试看起来都是一样的。
让我们看一下 MockManager 类。现在这会显得很复杂，但请记住，我们只编写一次并多次使用它。该类的整体复杂性是为了使单元测试易于人类阅读，易于理解、更新和维护。
public class CalculatorMockManager
{
private readonly Dictionary<OperationType,Mock<IOperation>> operationMocks = new();
public Mock<ITokenParser> TokenParserMock { get; } = new();
public Mock<IMathOperationFactory> MathOperationFactoryMock { get; } = new();
public Mock<ICache> CacheMock { get; } = new();
public Mock<ILogger> LoggerMock { get; } = new();
public CalculatorMockManager WithParsedTokens(List<CalculatorToken> tokens)
{
TokenParserMock
.Setup(m => m.Parse(It.IsAny<string>()))
.Returns(
new List<CalculatorToken> {
CalculatorToken.Addition, CalculatorToken.From(1), CalculatorToken.From(1)
}
);
return this;
}
public CalculatorMockManager WithOperation(OperationType operationType, int v1, int v2, int result)
{
var operationMock = new Mock<IOperation>();
operationMock
.Setup(m => m.Execute(v1, v2))
.Returns(result);
MathOperationFactoryMock
.Setup(m => m.GetOperation(operationType))
.Returns(operationMock.Object);
operationMocks[operationType] = operationMock;
return this;
}
public Calculator GetService()
{
return new Calculator(
TokenParserMock.Object,
MathOperationFactoryMock.Object,
CacheMock.Object,
LoggerMock.Object
);
}
public CalculatorMockManager VerifyOperationExecute(OperationType operationType, int v1, int v2, Func<Times> times)
{
MathOperationFactoryMock
.Verify(m => m.GetOperation(operationType), Times.AtLeastOnce);
var operationMock = operationMocks[operationType];
operationMock
.Verify(m => m.Execute(v1, v2), times);
return this;
}
}
测试类所需的所有模拟都被声明为公共属性，允许对单元测试进行任何自定义。有一个 GetService 方法，它将始终返回被测试类的实例，并且所有依赖项都完全模拟。然后还有 With* 方法，它们自动设置各种场景并始终返回模拟管理器，以便可以链接它们。您还可以使用特定的断言方法，尽管在大多数情况下您会将一些输出与预期值进行比较，因此这些只是为了抽象出 Moq 框架的Verify 方法。
此模式现在使测试编写与代码编写保持一致：
现在编写单元测试既简单又一致：
抽象并不止于模拟框架。相同的模式可以应用于每种编程语言！对于 TypeScript 或 JavaScript 或其他东西来说，模拟管理器构造将非常不同，但单元测试看起来几乎是一样的。
希望这有帮助！
以上是单元测试中的 MockManager - 用于模拟的构建器模式的详细内容。更多信息请关注PHP中文网其他相关文章！
