7
votes

Mockage de l'objet instancié interne

J'écris une classe de test pour tester ma classe "ImporterService". Ce service lit une intrigue et crée un objet de ses données. L'objet, dans ce cas, une classe de constructeurs est instanciée dans la classe "ImporterService". Pour tester ma classe "ImporterService", j'ai besoin de vérifier les invocations sur la classe Builder. Pour cela, je veux utiliser un cadre moqueur, mais comment est-il possible de créer une instance simulée de l'objet "Builder" en dehors de "ImporterService"?

La méthode de ma classe de My 'ImporterService' ressemble à: xxx

Je pensais à déplacer la création de la classe de constructeur dans une méthode protégée que je peux remplacer sur la configuration du test. Mais cette solution ne semble pas très gentil avec moi car la classe "ImporterService" fuit une certaine logique interne et permet de remplacer la méthode par d'autres classes que je ne veux pas.


0 commentaires

5 Réponses :


2
votes

Si vous utilisez une bibliothèque d'injection de dépendance (ressemblant à ressort), vous pouvez injecter un objet simulé à la place du constructeur à l'ImporterService. Ou vous pouvez remplacer l'appel au constructeur avec un appel à l'usine et utiliser l'usine, qui renvoie des moqueurs du code de test.


1 commentaires

Si vous utilisez un bon cadre moqueur, vous n'avez pas besoin de ressort ou d'un autre DI Cadre de vos tests unitaires. Sauf si vous êtes testnig votre câblage



0
votes

En supposant que vous utilisiez Mokito (je recommande ce cadre moqueur), vous pourrez suivre:

  @Test
    public void testFoo(@Mocked Builder builder) {
        new Expectations() {
            {
                new Builder();
                returns(builder);

                builder.setSomemethod()
                ...
            }
        };

        assertSame(builder,impoertesService.importFrom(...));
    }


0 commentaires

0
votes

Certains cadres moqueurs tels que PowerMock peuvent se moquer de la construction d'objets.


0 commentaires

0
votes

Vous pouvez modifier la signature de la fonction à quelque chose comme ceci:

public Builder importFrom(BufferedReader reader, Builder builder) throws IOException {


0 commentaires

1
votes

Oui, vous pouvez le faire comme vous le suggérez ou:

Créer une classe d'usine dans laquelle vous créez des objets Builder CODE> et attribuez-le à la classe Reader. Dans vos tests de l'unité, maquette cette usine et forcer à construire un Builder code> de votre choix que vous pouvez rechercher des appels de méthode dans votre test de l'unité. p>

Voici un exemple en utilisant EasyMock montrant comment vous pouvez y parvenir: P>

Reader classUnderTest = new Reader();
BuilderFactory fakeFactory = EasyMock.createNiceMock(BuilderFactory.class);
Builder builder = EasyMock.createMock(Builder.class);
EasyMock.expect(fakeFactory.buildBuilder()).andReturn(builder);
builder.someMethod("value here");
EasyMock.expectLastCall().once();
EasyMock.replay(fakeFactory, builder);
classUnderTest.importFrom(bufferReader);
// Very that all calls were correctly performed on the builder
EasyMock.verify(builder);


0 commentaires