Vor ein paar Jahren habe ich darüber geschrieben, allerdings weniger ausführlich. Hier ist eine verfeinerte Version derselben Idee.
Unit-Tests sind für Entwickler sowohl Segen als auch Fluch. Sie ermöglichen ein schnelles Testen der Funktionalität, lesbare Anwendungsbeispiele und ein schnelles Experimentieren von Szenarien nur für die beteiligten Komponenten. Aber sie können auch chaotisch werden, müssen bei jeder Codeänderung gewartet und aktualisiert werden und können, wenn sie träge gemacht werden, Fehler nicht eher verbergen, als dass sie aufgedeckt werden.
Ich denke, der Grund dafür, dass Unit-Tests so schwierig sind, liegt darin, dass sie mit Testen verbunden sind, mit etwas anderem als dem Schreiben von Code, und außerdem darin, dass Unit-Tests anders geschrieben werden als die meisten anderen Codes, die wir schreiben.
In diesem Beitrag werde ich Ihnen ein einfaches Muster zum Schreiben von Unit-Tests vorstellen, das alle Vorteile hervorhebt und gleichzeitig die meisten kognitiven Dissonanzen mit normalem Code beseitigt. Unit-Tests bleiben lesbar und flexibel, während doppelter Code reduziert wird und keine zusätzlichen Abhängigkeiten hinzugefügt werden.
Aber zuerst definieren wir eine gute Unit-Test-Suite.
Um eine Klasse richtig zu testen, muss sie auf eine bestimmte Art und Weise geschrieben sein. In diesem Beitrag werden wir Klassen behandeln, die die Konstruktorinjektion für Abhängigkeiten verwenden, was meine empfohlene Methode zur Abhängigkeitsinjektion ist.
Um es dann zu testen, müssen wir Folgendes tun:
Aber das ist leichter gesagt als getan, denn es impliziert auch:
Wer liebt das?
Die Lösung besteht darin, das Builder-Softwaremuster zu verwenden, um flüssige, flexible und lesbare Tests in der Arrange-Act-Assert-Struktur zu erstellen und gleichzeitig Setup-Code in einer Klasse zu kapseln, die die Unit-Test-Suite für einen bestimmten Dienst ergänzt. Ich nenne das das MockManager-Muster.
Beginnen wir mit einem einfachen Beispiel:
// 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;
}
}
Dies ist traditionell ein Taschenrechner. Es empfängt eine Zeichenfolge und gibt einen ganzzahligen Wert zurück. Außerdem wird das Ergebnis für eine bestimmte Eingabe zwischengespeichert und einige Dinge protokolliert. Die eigentlichen Operationen werden von IMathOperationFactory abstrahiert und die Eingabezeichenfolge wird von einem ITokenParser in Token übersetzt. Keine Sorge, dies ist keine echte Klasse, sondern nur ein Beispiel. Schauen wir uns einen „traditionellen“ Test an:
[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);
}
Lass es uns ein wenig auspacken. Wir mussten für jede Konstruktorabhängigkeit einen Mock deklarieren, auch wenn uns beispielsweise der Logger oder der Cache eigentlich egal sind. Wir mussten auch eine Mock-Methode einrichten, die im Fall der Operation Factory einen anderen Mock zurückgibt.
In diesem speziellen Test haben wir hauptsächlich Setup geschrieben, eine Zeile Act und zwei Zeilen Assert. Wenn wir außerdem testen möchten, wie der Cache innerhalb der Klasse funktioniert, müssten wir das Ganze kopieren und einfügen und einfach die Art und Weise ändern, wie wir den Cache-Mock einrichten.
Und da sind noch die negativen Tests zu berücksichtigen. Ich habe viele negative Tests gesehen, die so etwas machten wie: „Einrichten, was fehlschlagen soll. Testen, dass es fehlschlägt“, was viele Probleme mit sich bringt, vor allem, weil es aus völlig anderen Gründen fehlschlagen kann und meistens diese Tests folgen eher der internen Implementierung der Klasse als ihren Anforderungen. Ein ordnungsgemäß negativer Test ist eigentlich ein vollständig positiver Test mit nur einer falschen Bedingung. Der Einfachheit halber ist dies hier nicht der Fall.
Also, ohne weitere Umschweife, hier ist derselbe Test, aber mit einem 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);
}
Beim Auspacken wird weder Cache noch Logger erwähnt, da wir dort keine Einrichtung benötigen. Alles ist verpackt und lesbar. Das Kopieren, Einfügen und Ändern einiger Parameter oder Zeilen ist nicht mehr hässlich. In Arrange werden drei Methoden ausgeführt, eine in Act und eine in Assert. Es werden nur die kleinsten spöttischen Details abstrahiert: Das Moq-Framework wird hier nicht erwähnt. Tatsächlich würde dieser Test gleich aussehen, unabhängig davon, für welches Spott-Framework man sich entscheidet.
Werfen wir einen Blick auf die MockManager-Klasse. Das mag zwar kompliziert erscheinen, aber denken Sie daran, dass wir es nur einmal schreiben und es viele Male verwenden. Die ganze Komplexität der Klasse dient dazu, Unit-Tests für Menschen lesbar, leicht zu verstehen, zu aktualisieren und zu warten.
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;
}
}
Alle erforderlichen Mocks für die Testklasse werden als öffentliche Eigenschaften deklariert, sodass ein Komponententest beliebig angepasst werden kann. Es gibt eine GetService-Methode, die immer eine Instanz der getesteten Klasse zurückgibt, wobei alle Abhängigkeiten vollständig simuliert sind. Dann gibt es With*-Methoden, die verschiedene Szenarien atomar einrichten und immer den Mock-Manager zurückgeben, sodass sie verkettet werden können. Sie können auch bestimmte Methoden zur Bestätigung verwenden, obwohl Sie in den meisten Fällen eine Ausgabe mit einem erwarteten Wert vergleichen werden. Diese dienen also nur dazu, die Verify-Methode des Moq-Frameworks zu abstrahieren.
Dieses Muster gleicht nun das Schreiben von Tests mit dem Schreiben von Code aus:
Jetzt einen Unit-Test zu schreiben ist trivial und konsistent:
Die Abstraktion hört nicht beim spöttischen Rahmen auf. Das gleiche Muster kann in jeder Programmiersprache angewendet werden! Das Mock-Manager-Konstrukt wird für TypeScript, JavaScript oder etwas anderes sehr unterschiedlich sein, aber der Unit-Test würde ziemlich gleich aussehen.
Ich hoffe, das hilft!
Das obige ist der detaillierte Inhalt vonMockManager in Unit-Tests – ein Builder-Muster, das für Mocks verwendet wird. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
