J'ai une situation où j'ai besoin de Mock du code de la production. Ceci est pour faire une partie du code, travailler en demi fonctionnalité.
Je dois choisir d'écrire des classes vides (pour mettre en œuvre l'interface) ou utiliser un système moqueur comme MOQ. P>
La question est donc la question, faites les systèmes moqueurs Mise à jour forte>
Exemple: P> interface IRocketSystem
{
void LaunchTheRocket();
}
class SimulationRocketSystem:IRocketSystem
{
...
}
class RocketSystem:IRocketSystem
{
...
}
8 Réponses :
C'est peut-être un peu inhabituel, alors je serais clair dans mes commentaires, etc. Il s'agit de la fonctionnalité requise. Sinon, quelqu'un va être très confus quant à la manière dont le code de test l'a rendue à la production!
quant à la performance, comme toujours, vous devez mesurer cela puisqu'il est si précis. Cependant, je suppose que je suppose que, comme vous vous moquez de la fonctionnalité que vous ne vous moquez pas, cela pourrait bien être La solution réelle est de fournir une implémentation factice à une interface existante et de fournir la mise en œuvre réelle ultérieurement.
Je ne connais pas vraiment des problèmes de performance. Mais imho, vous devez vraiment faire attention à la lisibilité. N'est-il pas préférable de déclarer une ou plusieurs interfaces et de la mettre en œuvre deux manières différentes?
- Modifier
Mocking pourrait être plus facile et utiliser moins de lignes de code, mais elle augmente la courbe d'apprentissage de votre code. Si un nouveau gars vient et voyez votre code, il aura besoin de plus de temps pour comprendre. Personnellement, je pense que c'est une caractéristique non encore implémentée du code. Mais s'il y avait une autre mise en œuvre de l'interface, ou une autre bonne décision de conception, je "l'obtiendrais" beaucoup plus vite et je me sentirais plus sécurisé pour changer le code.
Eh bien, c'est une opinion personnelle. Votre code utilisera un motif différent de ce qui est attendu. Il est similaire à la "convention sur la configuration". Si vous n'utilisez pas la convention, vous devriez avoir du mal à la configurer (dans votre cas, documenter et préciser ce que vous faites).
Une des implémentations est la classe d'espèce, mais dans le système simulé est une ligne de code. Alors personnellement, je pense au système moqueur
@Avram a édité ma réponse, donnant plus d'arguments. C'est plus facile, mais j'hho c'est plus déroutant (et donc moins lisible)
Le nouveau gars doit apprendre des tests unitaires. J'utilise pour tester beaucoup de moqueurs.
Qu'est-ce qui ne va pas avec une classe vide?
En effet, il sera remplacé par une classe réelle, vous pouvez aussi bien commencer par une classe réelle.
Je pense que mettre un code simulé de tout type externe est une mauvaise politique.
+1, ma préférence serait de faire un peu de travail supplémentaire et d'écrire mon propre simulacre / bout plutôt que d'expédier la fausse framework pour faciliter l'utilisation du talon.
J'ai une classe entièrement mise en œuvre, mais parfois, je n'ai pas besoin de toutes les fonctionnalités (comme dans l'exemple)
"Parfois, je n'ai pas besoin de toutes les fonctionnalités" n'est pas pertinente. Vous avez la classe, vous l'utilisez. Le but est que la production soit complètement cohérente, pas petite. En utilisant des simulacres dans la production pour remplacer le code work est effrayant.
Je dois choisir d'écrire des classes vides ou d'utiliser un système moqueur comme MOQ.
En l'enveloppant dans un composant de façade / adaptateur dédié et à l'aide de classes intérieures devrait suffire. Si vos classes vides doivent être transmises autour du système, vous avez un problème.
Non. Passage des classes vides est un modèle de conception .
Un objet maquette est quelque chose que vous utilisez pour les tests, car cela vous laissera affirmer que cela s'appelait correctement. Cela me semble que ce que vous cherchez, c'est plus comme un talon ou un objet proxy.
Puisque vous finirez éventuellement à mettre en œuvre la classe en question, il serait peu logique d'avoir un cadre simulé pour vous pour vous IMO. Pourquoi ne pas simplement créer la classe et la mettre en œuvre au besoin.
Pourquoi j'ai besoin de faire quelque chose que le système moqueur de faire mieux que moi?
J'ai eu l'impression que la raison pour laquelle les autres objets n'étaient pas présents pour le moment étaient parce que les classes nécessaires n'étaient pas encore implémentées. Si tel est bien le cas, je préférerais une classe de proxy car cela vous permettrait de connecter les objets en question au besoin. C'est à dire. Votre proxy pourrait transférer des appels vers les objets réels lorsque les fonctionnalités nécessaires deviennent disponibles.
Correct, j'utilise le système simulé comme système qui générant un objet Stub, mais j'ai une question, si je peux le faire en production.
Vous pouvez faire cela, mais pourquoi voudriez-vous? Depuis que vous mettrez éventuellement mettre en œuvre les classes nécessaires, pourquoi ne pas simplement commencer par la mise en œuvre d'un proxy. Si vous utilisez des talons de votre framework moqueur, vous devrez modifier le code lorsque vous commencez à mettre en œuvre les classes actuelles.
Mon conseil - ne le mettez pas en production. Ne mettez jamais rien dans la production capable de le ralentir, de le casser ou de perdre votre travail :)
Mais 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 sur votre propre - elle s'appelle Cya.
Bon point, mais je parle de projet où je ne suis que le responsable.
Peu importe - le processus est de protéger contre de mauvais changements, peu importe qui travaille sur le projet et qui est responsable.
Vous l'appelez, mais cela semble être ce que vous faites est juste une séparation appropriée de préoccupation.
C'est une bonne chose à utiliser le polymorphisme sur les déclarations si elles-mêmes pour contrôler ce qui devrait arriver.
exemple, dites si vous voulez que la journalisation soit optionnelle. L'approche impérative consiste à fournir un Mais si vous séparez plutôt le code de journal réel comme préoccupation pour un autre objet, vous pouvez définir cet objet sur lequel vous voulez. En plus de disposer d'un enregistreur null-routé qui représente la journalisation désactivée et celle qui écrit dans un fichier, elle vous permet également de fournir un objet de journalisation qui écrit à une base de données au lieu d'un fichier, il vous permet d'ajouter des fonctionnalités à l'enregistreur, telle comme rotation de fichier journal.
C'est simplement une bonne programmation orientée objet. boolean islogging . Ensuite, chaque fois vérifier le booléen comme si (islogging) {... Code de la journalisation ...} .
Oui, mais dois-je créer des classes vides ou utiliser un système qui facilite la tâche
Je n'utiliserais pas EasyMock pour créer la classe vide. Créez la classe null-routée (qui ne fait rien dans ses méthodes), puis héritez-la de la classe de journalisation et de remplacement des méthodes pour faire quelque chose. Pour un bonus supplémentaire, vous devez utiliser une injection de dépendance.
sonne comme un Null objet . Je ne crois pas à l'aide de cadres moqueurs pour cela pour deux raisons.
D'abord, ça fait mal la lisibilité. Vous implémentant l'interface avec une classe vide appropriée du nom, alors vous documenter à l'intérieur l'intention de cette classe. D'autre part, si vous utilisez un cadre moqueur, la documentation doit être intégrée quelque part dans le code. En outre, il sera source de confusion que les gens ont tendance à attendre se moque dans le code de test et ne pas comprendre votre intention d'utilisation se moque.
Deuxièmement, vous devez considérer ce qui se passe si quelqu'un modifie l'interface. Que faire si une méthode est ajoutée? Faut-il par défaut de retourner null - que certains cadres feraient? Que faire si la méthode doit retourner une valeur de retour spécifique selon le contrat d'interface. Si vous avez une mise en œuvre concrète, le compilateur au moins vous protéger un peu. Si vous utilisez un cadre moqueur, vous pouvez être hors de la chance.
Pouvez-vous partager du code ou nous donner plus de détails? Y a-t-il seulement des "fonctionnalités complètes" ou "demi fonctionnalité"? Ou est-ce complètement configurable?