몇 년 전에 이에 대해 글을 썼지만 자세한 내용은 적습니다. 동일한 아이디어의 좀 더 세련된 버전이 있습니다.
단위 테스트는 개발자에게 유익하기도 하고 해롭기도 합니다. 이를 통해 기능에 대한 빠른 테스트, 읽기 쉬운 사용 예, 관련된 구성 요소에 대한 시나리오의 빠른 실험이 가능합니다. 그러나 코드가 변경될 때마다 유지 관리 및 업데이트가 필요하고, 게으르게 수행하면 버그를 공개하는 대신 숨길 수 없게 됩니다.
단위 테스트가 그렇게 어려운 이유는 그것이 코드 작성 이외의 테스트와 연관되어 있고 또한 단위 테스트가 우리가 작성하는 대부분의 다른 코드와 반대되는 방식으로 작성되기 때문이라고 생각합니다.
이 게시물에서는 일반적인 코드의 인지 부조화를 대부분 제거하면서 모든 이점을 향상시키는 간단한 단위 테스트 작성 패턴을 제공하겠습니다. 단위 테스트는 읽기 쉽고 유연한 상태를 유지하는 동시에 중복 코드를 줄이고 추가 종속성을 추가하지 않습니다.
하지만 먼저 좋은 단위 테스트 모음을 정의해 보겠습니다.
클래스를 제대로 테스트하려면 특정 방식으로 작성해야 합니다. 이 게시물에서는 종속성 주입을 수행하는 데 제가 권장하는 방법인 종속성에 대한 생성자 주입을 사용하는 클래스를 다룰 것입니다.
그런 다음 테스트하려면 다음을 수행해야 합니다.
하지만 다음과 같은 의미도 있기 때문에 말처럼 실천하기는 쉽지 않습니다.
누가 좋아하나요?
해결책은 빌더 소프트웨어 패턴을 사용하여 Align-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);
}
포장을 풀면 어떤 설정도 필요하지 않기 때문에 캐시나 로거에 대한 언급이 없습니다. 모든 것이 포장되어 있고 읽을 수 있습니다. 이것을 복사하여 붙여넣고 몇 가지 매개변수나 일부 줄을 변경하는 것은 더 이상 보기 흉하지 않습니다. Align에는 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 프레임워크의 확인 방법을 추상화하기 위한 것입니다.
이제 이 패턴은 테스트 작성과 코드 작성을 일치시킵니다.
이제 단위 테스트 작성은 간단하고 일관성이 있습니다.
추상화는 조롱 프레임워크에서 끝나지 않습니다. 모든 프로그래밍 언어에 동일한 패턴을 적용할 수 있습니다! 모의 관리자 구성은 TypeScript나 JavaScript 등의 경우 매우 다르지만 단위 테스트는 거의 동일하게 보입니다.
도움이 되기를 바랍니다!
위 내용은 단위 테스트의 MockManager - 모의에 사용되는 빌더 패턴의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
