Comment se moquer de la construction d'objet?

StackOverflow https://stackoverflow.com/questions/91981

  •  01-07-2019
  •  | 
  •  

Question

Existe-t-il un moyen de simuler la construction d'objet à l'aide de JMock en Java?

Par exemple, si j'ai une méthode en tant que telle: 

public Object createObject(String objectType) {
    if(objectType.equals("Integer") {
        return new Integer();
    } else if (objectType.equals("String") {
        return new String();
    }
}

... y a-t-il un moyen de simuler l'attente de la construction de l'objet dans une méthode de test?

J'aimerais pouvoir espérer que certains constructeurs sont appelés plutôt que de disposer d'un peu de code pour vérifier le type (car il ne sera pas toujours aussi compliqué et simple que mon exemple).

Donc au lieu de: 

assertTrue(a.createObject() instanceof Integer);

Je pouvais espérer que le certain constructeur soit appelé. Juste pour le rendre un peu plus propre, et exprimer ce qui est réellement testé de manière plus lisible.

Veuillez excuser le simple exemple. Le problème sur lequel je travaille est un peu plus compliqué, mais espérer le simplifierait.

Pour un peu plus de contexte:

J'ai une méthode de fabrique simple, qui crée des objets wrapper. Les objets encapsulés peuvent nécessiter des paramètres difficiles à obtenir dans une classe de test (c'est du code préexistant), il est donc difficile de les construire.

Peut-être que ce que je recherche le plus proche est le suivant: existe-t-il un moyen de se moquer de toute une classe (en utilisant CGLib) en un seul coup, sans spécifier toutes les méthodes à supprimer?

Donc, la maquette est encapsulée dans un constructeur, de sorte que les méthodes peuvent évidemment être appelées, est-ce que JMock est capable de simuler de manière dynamique chaque méthode?

Je suppose que non, car ce serait assez compliqué. Mais savoir que je me trompe d’arbre est également précieux: -)

Était-ce utile?

La solution

La seule chose à laquelle je peux penser, c’est d’avoir la méthode create sur l’objet usine, ce que vous feriez bien.

Mais pour ce qui est de se moquer d'un appel de constructeur, non. Les objets fictifs présupposent l'existence de l'objet, alors qu'un constructeur présuppose que l'objet n'existe pas. Au moins en Java où l’allocation et l’initialisation se déroulent ensemble.

Autres conseils

jmockit peut le faire.

Voir ma réponse dans https://stackoverflow.com/questions/22697#93675

Hélas, je pense être coupable d'avoir posé la mauvaise question.

L’usine simple que j’essayais de tester ressemblait à quelque chose comme: 

public Wrapper wrapObject(Object toWrap) {
    if(toWrap instanceof ClassA) {
        return new Wrapper((ClassA) toWrap);
    } else if (toWrap instanceof ClassB) {
        return new Wrapper((ClassB) toWrap);
    } // etc

    else {
        return null;
    }
}

Je demandais comment savoir si "new ClassAWrapper ()" a été appelé car l’objet toWrap était difficile à obtenir lors d’un test isolé. Et le wrapper (si on peut même l'appeler ainsi) est un peu bizarre, car il utilise la même classe pour envelopper différents objets, mais utilise différents constructeurs [1]. Je pense que si j'avais posé la question un peu mieux, j'aurais rapidement reçu la réponse:

"Vous devez mimer l'objet toWrap pour qu'il corresponde aux instances que vous testez dans différentes méthodes de test, et inspectez l'objet Wrapper résultant pour trouver le type correct est renvoyé ... et espérez que vous avez la chance de le faire. ne pas avoir à se moquer du monde pour créer les différentes instances; -) "

J'ai maintenant une solution satisfaisante au problème immédiat, merci!

[1] poser la question de savoir si cela devrait être remanié est bien en dehors du cadre de mon problème actuel: -)

Connaissez-vous Injection de dépendance ?

Si non, alors vous auriez tout intérêt à en apprendre davantage sur ce concept. Je suppose que la bonne vieille Inversion des conteneurs de contrôle et du modèle d'injection de dépendance par Martin Fowler servira de bonne introduction.

Avec l’injection de dépendances (DI), vous disposez d’un objet conteneur DI, capable de créer toutes sortes de classes pour vous. Ensuite, votre objet utilisera le conteneur DI pour instancier des classes et vous simulerez le conteneur DI pour vérifier que la classe crée des instances des classes attendues.

Injection de dépendance ou inversion du contrôle.

Vous pouvez également utiliser le modèle de conception Abstract Factory pour tous les objets que vous créez. Lorsque vous êtes en mode de test unitaire, injectez une usine de test qui vous expliquera ce que vous créez, puis incluez le code d'assertion dans la fabrique de test pour vérifier les résultats (inversion du contrôle).

Pour laisser votre code aussi propre que possible, créez une interface protégée interne, implémentez l'interface (votre usine) avec le code de production en tant que classe interne. Ajoutez un type de variable statique de votre interface initialisée à votre fabrique par défaut. Ajoutez un setter statique pour l’usine et vous avez terminé.

Dans votre code de test (doit figurer dans le même package, sinon l'interface interne doit être publique), créez une classe anonyme ou interne avec le code d'assertion et le code de test. Dans votre test, initialisez ensuite la classe cible, affectez (injectez) la fabrique de test et exécutez les méthodes de votre classe cible.

J'espère qu'il n'y en a pas. Les simulacres sont supposés simuler des interfaces, qui n'ont pas de constructeurs ... juste des méthodes.

Quelque chose ne va pas dans votre approche de test ici. Pourquoi avez-vous besoin de vérifier que les constructeurs explicites sont appelés?
Affirmer le type d'objet renvoyé semble correct pour tester les implémentations d'usine. Traitez createObject comme une boîte noire. Examinez ce qu’il renvoie, mais ne microgérez pas comment il le fait. Personne n'aime ça:)

Mise à jour sur la mise à jour: Ouch! Des mesures désespérées pour des temps désespérés hein? Je serais surpris que JMock permette cela ... comme je l'ai dit, cela fonctionne sur les interfaces ... pas de types concrets. Donc

  • Soit vous essayez de déployer des efforts pour rendre ces objets d'entrée embêtants 'instanciables' sous le faisceau de test. Go Bottom up dans votre approche.
  • Si cela est impossible, testez-le manuellement avec des points d'arrêt (je sais que ça craint). Collez ensuite un message "Touchez-le à vos risques et périls". commentez dans une zone visible du fichier source et avancez. Combattez un autre jour.
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top