Devrais-je utiliser moqueur dans le code de production?

Question

Je me trouve dans une situation où je dois simuler du code en production. C'est pour faire une partie du code, travailler dans la moitié des fonctionnalités.

Je dois choisir d'écrire des classes vides (pour implémenter l'interface) ou d'utiliser un système moqueur comme moq.

La question est donc de savoir si les systèmes moqueurs atteignent les performances ou brisent une partie de la lisibilité du code de production?

mettre à jour
exemple:

interface IRocketSystem
{
   void LaunchTheRocket();
}

class SimulationRocketSystem:IRocketSystem
{
...
}

class RocketSystem:IRocketSystem
{
...
}

J'ai constaté que les classes de production SimulationRocketSystem étaient aussi petites que petites et qu'elles n'avaient pas beaucoup dans le corps. le système fictif a une ligne de code ( nouveau Mock < IRocketSystem > (). Object ) pour remplacer des classes comme celle-ci.

les pros de la dérision:
classes moins vides dans le projet.

Answer 1

Cela ressemble à un objet null . Je ne crois pas à l’utilisation des frameworks moqueurs pour cela pour deux raisons.

Tout d’abord, cela nuit à la lisibilité. Vous implémentez l'interface avec une classe vide nommée de manière appropriée, puis vous documentez l'intention dans cette classe. D'autre part, si vous utilisez un framework moqueur, votre documentation doit être intégrée quelque part dans le code. De plus, cela sera source de confusion, car les gens s'attendent généralement à des simulacres dans le code de test et ne comprennent pas votre intention de les utiliser.

Deuxièmement, vous devez tenir compte de ce qui se passe si quelqu'un modifie l'interface. Et si une méthode est ajoutée? Devrait-il revenir par défaut à null - comme certains frameworks le feraient? Et si la méthode doit renvoyer une valeur de retour spécifique conformément au contrat d'interface. Si vous avez une implémentation concrète, le compilateur vous protégera au moins un peu. Si vous utilisez un framework moqueur, vous n’auriez peut-être pas de chance.

Answer 2

Un objet fictif est quelque chose que vous utilisez pour les tests, car il vous permettra d'affirmer qu'il a été appelé correctement. Il me semble que ce que vous recherchez ressemble davantage à un objet de remplacement ou à un objet proxy.

Etant donné que vous allez éventuellement implémenter la classe en question, il serait peu logique de disposer d’un cadre factice pour le faire pour vous, OMI. Pourquoi ne pas simplement créer la classe et l'implémenter au besoin.

Answer 3

Qu'est-ce qui ne va pas avec une classe vide?

En effet, il sera remplacé par une vraie classe. Vous pouvez donc commencer par une vraie classe.

Je pense que mettre du code factice de toute sorte en dehors des tests est une mauvaise politique.

Answer 4

Vous appelez ça de la moqueur, mais il semble que ce que vous faites est simplement une séparation appropriée des préoccupations.

C’est une bonne chose d’utiliser le polymorphisme sur des instructions if pour contrôler ce qui devrait se passer.

Exemple, si vous souhaitez que la journalisation soit facultative. L’approche impérative consiste à fournir un boolean isLogging. Puis à chaque fois, vérifiez le booléen comme if (isLogging) { ...logging code... }.

Mais si vous séparez le code de journal réel en tant que problème pour un autre objet, vous pouvez définir cet objet sur un objet qui fait ce que vous voulez. En plus d’un enregistreur à routage nul qui représente la journalisation désactivée et qui écrit réellement dans un fichier, il vous permet également de fournir un objet de journalisation qui écrit dans une base de données au lieu d’un fichier, il vous permet d’ajouter des fonctionnalités au consignateur, telles que rotation de fichier journal.

C’est simplement une bonne programmation orientée objet.

Answer 5

C'est peut-être un peu inhabituel, alors je voudrais bien préciser dans mes commentaires, etc., que c'est une fonctionnalité requise. Sinon, quelqu'un sera très confus quant à la façon dont le code de test est parvenu à la production!

En ce qui concerne les performances, comme toujours, vous devez les mesurer car elles sont si spécifiques. Cependant, je suppose que si vous vous moquez d'une fonctionnalité que vous n'avez pas écrite, elle pourrait bien être beaucoup plus rapide que votre implémentation simulée. Vous devrez peut-être renseigner vos utilisateurs car, lorsque vous fournissez une mise en œuvre finale fonctionnelle, ils risquent de connaître des problèmes de performances: -)

La solution réelle consiste à fournir une implémentation factice à une interface existante et à fournir ultérieurement l'implémentation réelle.

Answer 6

Je ne connais pas vraiment les problèmes de performances. Mais à mon humble avis, vous devez faire très attention à la lisibilité. Ne vaut-il pas mieux déclarer une ou plusieurs interfaces et l’implémenter de deux manières différentes?

- EDIT

Il peut être plus simple de se moquer et d'utiliser moins de lignes de code, mais cela augmente la courbe d'apprentissage de votre code. Si un nouveau gars vient voir votre code, il aura besoin de plus de temps pour comprendre. Personnellement, je pense que c'est une fonctionnalité du code non encore implémentée. Mais s'il y avait une autre implémentation d'interface, ou une autre bonne décision de conception, & "L'obtenirais &"; beaucoup plus rapidement et me sentirais plus en sécurité avec le changement de code.

Eh bien, c'est un avis personnel. Votre code utilisera un modèle différent de celui attendu. Cela ressemble à la convention & "; Relative à la configuration &". Si vous n'utilisez pas la convention, vous devriez avoir plus de difficulté à la configurer (dans votre cas, documentez et expliquez ce que vous faites).

Answer 7

Mon conseil - ne le mettez pas en production. Ne mettez jamais dans la production quoi que ce soit qui puisse le ralentir, le casser ou provoquer votre perte d'emploi:)

Mais ce qui est plus important que ce que je pense, c’est quelle est la politique de votre entreprise et que pense votre responsable? Vous ne devriez jamais penser à prendre une décision comme celle-ci par vous-même - cela s'appelle ACY.

Answer 8

  

Je dois choisir d'écrire des classes vides ou d'utiliser un système moqueur comme moq.

Envelopper dans un composant dédié façade / adaptateur et utiliser des classes internes devrait suffire. Si vos classes vides doivent être transmises au système, vous avez un problème.