MockManager in Unit-Tests – ein Builder-Muster, das für Mocks verwendet wird

Vor ein paar Jahren habe ich darüber geschrieben, allerdings weniger ausführlich. Hier ist eine verfeinerte Version derselben Idee.

Einführung

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.

So führen Sie einen Unit-Test durch

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:

• Positive Szenarien abdecken – wenn die Klasse das tut, was sie tun soll, mit verschiedenen Kombinationen von Setup- und Eingabeparametern, um die gesamte Funktionalität abzudecken
• Negative Szenarien abdecken – wenn die Klasse auf die richtige Weise fehlschlägt, wenn die Einrichtungs- oder Eingabeparameter falsch sind
• alle externen Abhängigkeiten verspotten
• Behalten Sie den gesamten Testaufbau, die Aktion und die Behauptung im selben Test bei (was normalerweise als Arrange-Act-Assert-Struktur bezeichnet wird)

Aber das ist leichter gesagt als getan, denn es impliziert auch:

• Einrichten der gleichen Abhängigkeiten für jeden Test, wodurch viel Code kopiert und eingefügt werden muss
• Einrichten sehr ähnlicher Szenarien, mit nur einer Änderung zwischen zwei Tests und erneuter Wiederholung einer Menge Code
• nichts verallgemeinern und kapseln, was ein Entwickler normalerweise in seinem gesamten Code tun würde
• Viele negative Fälle für wenige positive Fälle schreiben, was sich anfühlt, als müsste man mehr Code als Funktionscode testen
• alle diese Tests müssen für jede Änderung an der getesteten Klasse aktualisiert werden

Wer liebt das?

Lösung

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);
}
</ilogger></icache></ioperation></imathoperationfactory></calculatortoken></string></itokenparser>

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);
}

</calculatortoken>

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>> 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;
    }
}
</times></ioperation></calculatortoken></string></calculatortoken></ilogger></icache></imathoperationfactory></itokenparser></operationtype>

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.

Abschluss

Dieses Muster gleicht nun das Schreiben von Tests mit dem Schreiben von Code aus:

• Abstrahieren Sie die Dinge, die Ihnen in keinem Kontext wichtig sind
• Einmal schreiben und mehrmals verwenden
• Menschenlesbarer, selbstdokumentierender Code
• kleine Methoden mit geringer zyklomatischer Komplexität
• Intuitives Schreiben von Code

Jetzt einen Unit-Test zu schreiben ist trivial und konsistent:

1. Instanziieren Sie den Mock-Manager der Klasse, die Sie testen möchten (oder schreiben Sie einen basierend auf den obigen Schritten)
2. Erstellen Sie spezifische Szenarien für den Test (mit automatischer Vervollständigung für vorhandene, bereits abgedeckte Szenarioschritte)
3. Führen Sie die Methode aus, die Sie testen möchten, mit Testparametern
4. Überprüfen Sie, ob alles wie erwartet ist

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!