Il y a quelques années, j'ai écrit à ce sujet, mais avec moins de détails. Voici une version plus raffinée de la même idée.

Introduction

Les tests unitaires sont à la fois une aubaine et un fléau pour les développeurs. Ils permettent des tests rapides de fonctionnalités, des exemples d'utilisation lisibles, une expérimentation rapide de scénarios uniquement pour les composants impliqués. Mais ils peuvent également devenir compliqués, nécessiter une maintenance et une mise à jour à chaque changement de code et, lorsqu'ils sont effectués paresseusement, ne peuvent pas cacher les bogues plut?t que de les révéler.

Je pense que la raison pour laquelle les tests unitaires sont si difficiles est qu'ils sont associés aux tests, à autre chose que l'écriture de code, et aussi que les tests unitaires sont écrits d'une manière opposée à la plupart des autres codes que nous écrivons.

Dans cet article, je vais vous donner un modèle simple d'écriture de tests unitaires qui améliorera tous les avantages, tout en éliminant la plupart des dissonances cognitives avec le code normal. Les tests unitaires resteront lisibles et flexibles, tout en réduisant le code en double et en n'ajoutant aucune dépendance supplémentaire.

Comment faire un test unitaire

Mais d'abord, définissons une bonne suite de tests unitaires.

Pour tester correctement un cours, il faut qu'il soit écrit d'une certaine manière. Dans cet article, nous couvrirons les classes utilisant l'injection de constructeur pour les dépendances, qui est la méthode que je recommande pour effectuer l'injection de dépendances.

Ensuite, afin de le tester, nous devons?:

• couvrir des scénarios positifs - lorsque la classe fait ce qu'elle est censée faire, avec diverses combinaisons de paramètres de configuration et d'entrée pour couvrir l'ensemble des fonctionnalités
• couvrir les scénarios négatifs - lorsque la classe échoue de la bonne manière lorsque la configuration ou les paramètres d'entrée sont erronés
• se moquer de toutes les dépendances externes
• conserver toute la configuration, l'action et l'assertion du test dans le même test (ce que l'on appelle normalement la structure Arrange-Act-Assert)

Mais c'est plus facile à dire qu'à faire, car cela implique aussi?:

• mettre en place les mêmes dépendances pour chaque test, donc copier et coller beaucoup de code
• mise en place de scénarios très similaires, avec juste un changement entre deux tests, en répétant là encore beaucoup de code
• généraliser et ne rien encapsuler, ce qu'un développeur ferait normalement dans tout son code
• écrire beaucoup de cas négatifs pour quelques cas positifs, ce qui donne l'impression d'avoir plus de code de test que de code fonctionnel
• devoir mettre à jour tous ces tests pour chaque changement apporté à la classe testée

Qui aime ?a ?

Solution

La solution consiste à utiliser le modèle logiciel builder pour créer des tests fluides, flexibles et lisibles dans la structure Arrange-Act-Assert, tout en encapsulant le code de configuration dans une classe complétant la suite de tests unitaires pour un service spécifique. J'appelle cela le modèle MockManager.

Commen?ons par un exemple simple?:

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

Il s'agit d'une calculatrice, comme le veut la tradition. Il re?oit une cha?ne et renvoie une valeur entière. Il met également en cache le résultat d'une entrée spécifique et enregistre certaines informations. Les opérations réelles sont résumées par IMathOperationFactory et la cha?ne d'entrée est traduite en jetons par un ITokenParser. Ne vous inquiétez pas, ce n'est pas un vrai cours, juste un exemple. Regardons un test "traditionnel":

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

Déballons-le un peu. Nous avons d? déclarer une simulation pour chaque dépendance du constructeur, même si nous ne nous soucions pas réellement du logger ou du cache, par exemple. Nous avons également d? mettre en place une méthode mock qui renvoie un autre mock, dans le cas de l'opération factory.

Dans ce test particulier, nous avons écrit principalement setup, une ligne d'Act et deux lignes d'Assert. De plus, si nous voulons tester le fonctionnement du cache à l'intérieur de la classe, nous devrons copier-coller le tout et simplement changer la fa?on dont nous configurons le cache simulé.

Et il y a les tests négatifs à considérer. J'ai vu de nombreux tests négatifs faire quelque chose comme?: "configurez exactement ce qui est censé échouer. testez qu'il échoue", ce qui introduit beaucoup de problèmes, principalement parce qu'il peut échouer pour des raisons complètement différentes et la plupart du temps, ces tests suivent l'implémentation interne de la classe plut?t que ses exigences. Un test négatif approprié est en fait un test entièrement positif avec une seule mauvaise condition. Ce n'est pas le cas ici, par souci de simplicité.

Alors, sans plus attendre, voici le même test, mais avec un 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);
}

Au déballage, il n'y a aucune mention de cache ou de logger, car nous n'y avons besoin d'aucune configuration. Tout est emballé et lisible. Copier coller ceci et changer quelques paramètres ou certaines lignes n'est plus moche. Il existe trois méthodes exécutées dans Arrange, une dans Act et une dans Assert. Seuls les moindres détails moqueurs sont résumés?: il n'y a aucune mention du framework Moq ici. En fait, ce test serait identique quel que soit le framework moqueur que l'on décide d'utiliser.

Jetons un coup d'?il à la classe MockManager. Maintenant, cela semble compliqué, mais rappelez-vous que nous n'écrivons ceci qu'une seule fois et que nous l'utilisons plusieurs fois. Toute la complexité de la classe est là pour rendre les tests unitaires lisibles par les humains, faciles à comprendre, à mettre à jour et à maintenir.

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

Tous les mocks requis pour la classe de test sont déclarés comme propriétés publiques, permettant toute personnalisation d'un test unitaire. Il existe une méthode GetService, qui renverra toujours une instance de la classe testée, avec toutes les dépendances entièrement simulées. Ensuite, il existe des méthodes With* qui configurent atomiquement divers scénarios et renvoient toujours le gestionnaire fictif, afin qu'ils puissent être encha?nés. Vous pouvez également avoir des méthodes d'assertion spécifiques, bien que dans la plupart des cas, vous comparerez une sortie avec une valeur attendue, celles-ci sont donc ici juste pour résumer la méthode Verify du framework Moq.

Conclusion

Ce modèle aligne désormais l'écriture de tests avec l'écriture de code?:

• abstraire les choses qui ne vous intéressent dans aucun contexte
• écrivez une fois et utilisez plusieurs fois
• Code humainement lisible et auto-documenté
• petites méthodes à faible complexité cyclomatique
• écriture de code intuitive

écrire un test unitaire maintenant est trivial et cohérent?:

1. instanciez le gestionnaire fictif de la classe que vous souhaitez tester (ou écrivez-en un en fonction des étapes ci-dessus)
2. composer des scénarios spécifiques pour le test (avec saisie semi-automatique pour les étapes de scénario existantes déjà couvertes)
3. exécutez la méthode que vous souhaitez tester avec les paramètres de test
4. vérifiez que tout se passe comme prévu

L'abstraction ne s'arrête pas au cadre moqueur. Le même modèle peut être appliqué dans tous les langages de programmation?! La construction du gestionnaire fictif sera très différente pour TypeScript, JavaScript ou autre chose, mais le test unitaire ressemblerait à peu près à la même chose.

J'espère que cela vous aidera?!

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!