Fermer

août 16, 2022

Se moquer des meilleures pratiques

Se moquer des meilleures pratiques


Le mocking ne consiste pas seulement à isoler le code testé, il s’agit également de créer des tests plus rapides et plus simples. Mais, si vous ne le faites pas correctement, la moquerie peut également générer plus de code à gérer et à entretenir. Les meilleures pratiques avec les outils de simulation garantissent que toutes vos simulations ajoutent de la valeur à vos tests sans augmenter les coûts.

L’objectif principal de la moquerie dans les tests automatisés est d’isoler le « code sous test » (CUT). Isoler le CUT présente de nombreux avantages, mais le plus important est que, lorsqu’un test échoue, vous savez exactement où est le problème : c’est dans le CUT. Il existe, bien sûr, d’autres raisons de créer des objets factices : par exemple, se moquer d’une base de données peut considérablement accélérer les tests en éliminant les allers-retours vers le serveur de base de données et se moquer des périphériques matériels/réseaux peut simplifier les tests tout en vous permettant d’exécuter des tests lorsque ces périphériques ne fonctionnent pas. n’est pas disponible.

Quelle que soit la raison pour laquelle vous utilisez des simulations, il existe certaines bonnes pratiques que vous pouvez suivre pour réduire le coût des simulations tout en rendant vos simulations plus efficaces.

Coups rapides

Il y a un tas de choses que vous devez faire avant de commencer à mettre en œuvre les meilleures pratiques lors de la création de maquettes – éliminons-les d’abord. Après tout, bon nombre de ces meilleures pratiques peuvent échapper à votre contrôle :

En supposant que vous avez contribué à la décision, choisissez un cadre factice qui fonctionne bien avec votre cadre de test et vos outils de développement. Télérik JustMockpar exemple, qui cible l’environnement .NET, s’intègre à l’outil de développement principal du domaine : Visual Studio.

Écrire du code en utilisant les meilleures pratiques actuelles ou, si vous êtes un testeur, demandez aux développeurs de suivre les meilleures pratiques actuelles. De nos jours, les bonnes pratiques en écriture de code se résument en les principes SOLID pour le développement orienté objet. Cependant, le style de programmation actuel n’a pas vraiment d’importance : les outils de simulation vont prendre en charge les « meilleures pratiques actuelles en matière de développement d’applications », donc suivre ces meilleures pratiques sera toujours le choix intelligent. Donc, vraiment, cette meilleure pratique devrait se terminer par « … et ensuite rester à jour ».

Écrire du code faiblement couplé ou, comme ci-dessus, si vous êtes un testeur, demandez à vos développeurs/architectes d’écrire leur code de cette façon. Cette meilleure pratique est indépendante des « meilleures pratiques actuelles en matière de développement ». Atteindre l’un des objectifs de l’utilisation d’un objet fictif (isoler le CUT, éliminer les opérations chronophages, simplifier les tests) est considérablement plus facile dans les applications faiblement couplées. Cependant, cela dit, de puissants frameworks moqueurs comme JustMock vous permettront de vous moquer pratiquement n’importe quel code. Mais, alors que (avec les bons outils) vous boîte simuler du code étroitement couplé, cela prendra plus de temps et vous coûtera plus cher qu’avec du code faiblement couplé.

Décider de quoi se moquer

La première bonne pratique sur laquelle vous avez le contrôle est : N’écrivez pas plus de code moqueur que nécessaire. Le code moqueur est toujours « plus de code » et, comme tout autre code que vous écrivez, prend du temps à la fois pour créer et à maintenir. C’est tout le temps qui n’est pas consacré à l’ajout de fonctionnalités aux applications. Écrivez tout (et seulement) le code moqueur dont vous avez besoin… puis arrêtez.

La meilleure pratique suivante permet de spécifier ce dont vous devez vous moquer : Seuls les objets fictifs avec logique. Même si un objet fictif ne peut renvoyer qu’une valeur, son but est de remplacer quelque chose dans votre application qui contient de la logique et, par conséquent, dont l’impact sur le CUT est… eh bien, disons simplement, « imprévisible ».

Le corollaire de cette pratique est : Ne vous moquez pas des objets qui ne portent que des valeurs. Les objets utilisés uniquement pour transmettre des données (appelés « objets de valeur » ou « objets de transfert de données ») peuvent être créés dans vos tests à l’aide des classes d’origine.

Prochain, Soyez clair sur ce que vous voulez que le test prouve. Il n’est pas rare d’avoir un CUT qui appelle un objet, qui appelle un autre objet, qui appelle ensuite encore un autre objet. Si vous créez un test unitaire, vous voudrez probablement vous moquer du premier objet de la chaîne : se moquer du premier objet isole le CUT, ce qui est votre objectif typique dans un test unitaire.

Cependant, si vous faites un test d’intégration, vous voudrez peut-être vous moquer du dernier objet de la chaîne car le but de votre test est de voir ce qui se passe lorsque les objets interagissent. Un bon cadre de simulation vous permettra de le faire en vous moquant d’objets qui ne sont pas directement disponibles à partir du CUT (JustMock gère cela via avenir moqueurpar exemple).

Décider comment se moquer

Gardez vos simulations simples: Si tout ce dont vous avez besoin est que le mock renvoie une valeur ou un objet configuré, demandez simplement à votre mock object de le faire (généralement, c’est ce que les testeurs veulent dire quand ils se réfèrent à un « stub »). Si vous avez besoin d’un objet fictif pour signaler ce qui lui a été transmis, configurez le simulacre pour le faire (dans mon exemple précédent, l’objet fictif à la fin de la chaîne d’appel dans un test d’intégration peut simplement signaler ce qui, le cas échéant, données que la simulation a reçues via la chaîne d’appels d’objets).

Si vous commencez à faire en sorte que votre objet fictif en fasse plus – si, par exemple, vous commencez à écrire du code qui imite la logique métier réelle (ce que l’on appelle parfois une « simulation ») – alors vous manquez l’intérêt d’un objet fictif. Désormais, non seulement vous augmentez la quantité de code que vous devrez maintenir et modifier à mesure que votre application évolue, mais vous ajoutez également à la logique associée à votre application. Et cela soulève une question clé : comment, exactement, avez-vous l’intention de tester la logique à l’intérieur d’un objet factice ?

Lorsqu’il s’agit de créer une maquette, Préférez le code déclaratif. Idéalement, votre outil de simulation vous permettra de générer des simulations en indiquant ce que vous voulez que votre simulation fasse, puis de laisser le cadre de simulation se charger à la fois de créer et d’invoquer la simulation. Vous voulez éviter de vous moquer des outils qui nécessitent une sorte de logique pour créer ou utiliser une simulation – c’est juste plus de code dont vous aurez besoin (d’une manière ou d’une autre) pour tester.

Par exemple, tout le code requis dans JustMock pour se moquer d’une méthode appelée CalcCost sur un objet statique nommé MyStaticObject. Ces deux lignes de code :

  1. Marque que l’objet MyStaticUtility sera simulé.
  2. Spécifiez que la simulation de la méthode CalcCost sur cet objet fera deux choses :
    • Lève une exception si quelque chose d’autre qu’un objet Destination lui est passé.
    • Renvoyez toujours le nombre 42.
Mock.SetupStatic(typeof(MyStaticUtility), StaticConstructor.Mocked);
Mock.Arrange(() => MyStaticUtility
			.CalcCost(Arg.IsAny<Destination>()))
				.Returns(42);

Maintenant que vous vous êtes moqué de cette méthode CalcCost, tout code du test qui appelle cette méthode utilisera automatiquement cette simulation.

La dernière meilleure pratique

Pour terminer, Reconnaître les limites de la moquerie. Finalement, tester contre un objet fictif ne prouvera pas ce que vous voulez. Il viendra, par exemple, un moment où vous voudrez prouver que votre application fonctionne avec les données réelles de votre base de données (par exemple, lors de l’acceptation des utilisateurs ou des tests de fumée). Pour citer Vince Gill, « Ils ont arrêté de jouer Elvis. Ils vont arrêter de jouer avec vous. Il y aura des tests qui, pour que ces tests soient utiles, ne pourront pas utiliser de simulations.

Votre objectif est que chaque simulation que vous créez contribue à la valeur de vos tests sans alourdir votre charge de maintenance. Ces meilleures pratiques garantissent que chaque maquette que vous créez (et chacune que vous ne le faites pas create) fait exactement cela.

JustMock : L'outil de simulation le plus rapide et le plus flexible pour créer des tests unitaires - essayez gratuitement




Source link