


MockManager dans les tests unitaires - un modèle de générateur utilisé pour les simulations
Dec 19, 2024 pm 12:27 PMIl 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?:
- instanciez le gestionnaire fictif de la classe que vous souhaitez tester (ou écrivez-en un en fonction des étapes ci-dessus)
- composer des scénarios spécifiques pour le test (avec saisie semi-automatique pour les étapes de scénario existantes déjà couvertes)
- exécutez la méthode que vous souhaitez tester avec les paramètres de test
- 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!

Outils d'IA chauds

Undress AI Tool
Images de déshabillage gratuites

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
échangez les visages dans n'importe quelle vidéo sans effort grace à notre outil d'échange de visage AI entièrement gratuit?!

Article chaud

Outils chauds

Bloc-notes++7.3.1
éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Sujets chauds

Oui, la surcharge de la fonction est une forme polymorphe en C, en particulier le polymorphisme à temps de compilation. 1. La surcharge de fonction permet plusieurs fonctions avec le même nom mais différentes listes de paramètres. 2. Le compilateur décide de la fonction à appeler au moment de la compilation en fonction des paramètres fournis. 3. Contrairement au polymorphisme d'exécution, la surcharge de fonction n'a pas de frais généraux supplémentaires au moment de l'exécution et est simple à implémenter mais moins flexible.

C a deux types polymorphes principaux: le polymorphisme à temps de compilation et le polymorphisme d'exécution. 1. Le polymorphisme à temps de compilation est implémenté par la surcharge et les modèles de fonction, offrant une efficacité élevée mais peut conduire à des ballonnements de code. 2. Le polymorphisme d'exécution est implémenté via des fonctions virtuelles et l'héritage, offrant une flexibilité mais des surcharges de performances.

Oui, les polymorphismes en C sont très utiles. 1) Il offre une flexibilité pour permettre une addition facile de nouveaux types; 2) favorise la réutilisation du code et réduit la duplication; 3) simplifie la maintenance, ce qui rend le code plus facile à développer et à s'adapter aux modifications. Malgré les défis des performances et de la gestion de la mémoire, ses avantages sont particulièrement importants dans les systèmes complexes.

C DestructorScanLeadtoseveralComMonErrors.toavoidThem: 1) empêcher lesDoubleleteTIeBySettingPointerStonullPtorUsingsMartPointers.2) manchexceptions indestructorycatchingandloggingthem.3) useVirtualDontructor

Les polymorphismes en C sont divisés en polymorphismes d'exécution et en polymorphismes à temps de compilation. 1. Le polymorphisme d'exécution est implémenté via des fonctions virtuelles, permettant à la bonne méthode d'être appelée dynamiquement au moment de l'exécution. 2. Le polymorphisme à temps de compilation est implémenté par la surcharge et les modèles de fonction, offrant des performances et une flexibilité plus élevées.

Les gens qui étudient le transfert de Python à C la confusion la plus directe est: pourquoi ne pouvez-vous pas écrire comme Python? Parce que C, bien que la syntaxe soit plus complexe, fournit des capacités de contr?le sous-jacentes et des avantages de performance. 1. En termes de structure de syntaxe, C utilise des accolades bouclées {} au lieu de l'indentation pour organiser les blocs de code, et les types de variables doivent être explicitement déclarés; 2. En termes de gestion du système et de la mémoire, C n'a pas de mécanisme de collecte de déchets automatique et doit gérer manuellement la mémoire et faire attention à la libération des ressources. La technologie RAII peut aider la gestion des ressources; 3. Dans les fonctions et les définitions de classe, C doit accéder explicitement aux modificateurs, constructeurs et destructeurs, et prend en charge des fonctions avancées telles que la surcharge de l'opérateur; 4. En termes de bibliothèques standard, STL fournit des conteneurs et des algorithmes puissants, mais doit s'adapter aux idées de programmation génériques; 5

C polymorphismisclusedescompile-time, runtime, andemplatepolymorphism.1) compile-timepolymormususFunctionandOperoLoloadingForefficiency.

C polymorphismismeniqueduetoittscombinationofcompile-timendruntimepolymorphism, permettant à la permission de Bothefficiency et de laFlexibilité.
