Qu'est-ce qu'une maquette et quand devriez-vous l'utiliser?

Question

Je viens de lire l'article Wikipedia sur les objets fictifs , mais je ne suis pas encore tout à fait clair. sur leur but. Il semble que ce soient des objets créés par une structure de test lorsque l'objet lui-même serait trop complexe ou imprévisible (vous savez à 100% quelles sont les valeurs de l'objet fictif, car vous les maîtrisez entièrement).

Cependant, j’avais l’impression que tous les tests sont effectués avec des objets de valeurs connues, il me manque donc quelque chose. Par exemple, dans un projet de cours, nous avons été chargés d’une application de calendrier. Notre suite de tests consistait en objets d'événements dont nous savions exactement ce qu'ils étaient afin de pouvoir tester les interactions entre plusieurs objets d'événements, divers sous-systèmes et l'interface utilisateur. Je suppose que ce sont des objets fictifs, mais je ne sais pas pourquoi vous ne le feriez pas car sans les objets de valeurs connues, vous ne pouvez pas tester un système.

Answer 1

Un objet fictif n'est pas simplement un objet avec des valeurs connues. C’est un objet qui a la même interface qu’un objet complexe que vous ne pouvez pas utiliser dans le test (comme une connexion à une base de données et des ensembles de résultats), mais avec une implémentation que vous pouvez contrôler dans votre test.

Il existe des frameworks moqueurs qui vous permettent de créer ces objets à la volée et vous permettent en substance de dire quelque chose comme: Faites-moi un objet avec une méthode foo qui prend un int et retourne un bool. Quand je passe 0, il devrait retourner vrai. Ensuite, vous pouvez tester le code qui utilise foo () pour vous assurer qu’il réagit correctement.

Martin Fowler a un excellent article sur les moqueries:

• http://martinfowler.com/articles/mocksArentStubs.html

Answer 2

Pensez au cas classique des logiciels client et serveur. Pour tester le client, vous avez besoin du serveur. pour tester le serveur, vous avez besoin du client. Cela rend les tests unitaires pratiquement impossibles - sans utiliser de simulacres. Si vous vous moquez du serveur, vous pouvez tester le client séparément et inversement.

Le but de la maquette n’est pas de reproduire le comportement des choses qu’elle se moque. Il s’agit plus d’agir comme une simple machine à états dont les changements d’état peuvent être analysés par le framework de test. Ainsi, un client factice peut générer des données de test, les envoyer au serveur, puis analyser la réponse. Vous attendez une certaine réponse à une demande spécifique et vous pouvez donc tester si vous l'obtenez.

Answer 3

Je suis d'accord avec tout @Lou Franco dit et vous devriez absolument lire l'excellent article de Martin Fowler sur les doubles tests que @Lou Franco vous indique.

Le but principal de tout test double (faux, stub ou mock) est d’isoler l’objet testé afin que votre test unitaire ne teste que cet objet (et non ses dépendances et les autres types avec lesquels il collabore ou interagit avec).

Un objet fournissant l'interface dont dépend votre objet peut être utilisé à la place de la dépendance réelle, de sorte que des attentes puissent être placées quant à certaines interactions. Cela peut être utile, mais il existe une certaine controverse entre le test basé sur l’état et le test basé sur l’interaction. Un abus des attentes factices conduira à des tests fragiles.

Une autre raison des doubles tests est de supprimer les dépendances sur des bases de données, des systèmes de fichiers ou d’autres types coûteux à configurer ou à exécuter des opérations fastidieuses. Cela signifie que vous pouvez réduire au minimum le temps nécessaire pour tester à l'unité l'objet qui vous intéresse.

Answer 4

Voici un exemple: si vous écrivez du code qui remplit une base de données, vous pouvez vérifier si une méthode particulière a ajouté des données à la base de données.

La configuration d’une copie de la base de données à des fins de test pose le problème suivant: si vous supposez qu’il n’ya pas d’enregistrements avant l’appel de la méthode testée et un enregistrement après, vous devez restaurer la base de données à son état précédent, ce qui ajoute: à la surcharge pour l'exécution du test.

Si vous supposez qu'il n'y a qu'un seul enregistrement de plus qu'avant, il peut entrer en conflit avec un deuxième testeur (ou même un deuxième test dans le même code) qui se connecte à la même base de données, ce qui provoque des dépendances et fragilise les tests.

La maquette vous permet de garder les tests indépendants les uns des autres et faciles à configurer.

Ce n’est qu’un exemple - je suis sûr que d’autres pourront en fournir davantage.

Je suis entièrement d'accord avec les autres contributeurs sur ce sujet, en particulier avec la recommandation concernant l'article de Martin Fowler.

Answer 5

Vous pourriez être intéressé par notre livre, voir http: //www.growing-object -oriented-software.com/ . C'est en Java, mais les idées s'appliquent toujours.