L'instanciation d'objets lors de l'utilisation de Printemps, pour les essais vs production

Intérieure statique de la classe de configuration:
Lors de l'essai de Printemps composants que nous utilisons habituellement @RunWith(SpringJUnit4ClassRunner.class) et faire de notre classe @ContextConfiguration. En faisant de la classe @ContextConfiguration vous pouvez créer un intérieur de classe statique pour la configuration et le fait que vous avez le plein contrôle. Il vous définissez tous vous avez besoin que les haricots et les @Autowired dans votre test, ainsi que les dépendances qui peuvent être des simulacres ou des objets, en fonction du cas de test.

Composant de balayage de code de production:
Si il y a plus de composants nécessaires pour la tester, vous pouvez ajouter @ComponentScan mais nous essayons de le faire analyser uniquement les paquets dont il a besoin (c'est lorsque vous utilisez @Component annotation, mais dans votre cas, vous pouvez ajouter XML pour @ContextConfiguration). C'est un bon choix lorsque vous n'avez pas besoin de se moque et que vous avez une installation compliquée qui doit être la production comme. C'est bon pour les tests d'intégration où vous voulez tester la façon dont les composants interagissent les uns avec les autres fonctionnelle tranches que vous voulez tester.

Approche hybride: C'est le cas d'habitude quand vous avez beaucoup de haricots, qui doivent être de production comme, mais un ou deux doivent être des simulacres. Ensuite, vous pouvez @ComponentScan code de production, mais aussi ajouter une inner classe statique qui est @Configuration et y définir les haricots avec l'annotation @Primary qui remplacera la production de code de configuration pour que les haricots dans le cas de tests. C'est bon puisque vous n'avez pas besoin d'écrire de longues @Configuration avec tous les haricots, vous analysez ce que vous avez besoin et remplacer ce qui devrait être une fantaisie.

Dans votre cas, je aller avec la première approche comme ceci:

package org.world.hello;

import static org.junit.Assert.*;
import org.mockito.Mockito;
import org.junit.Test;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class RoomTest {

    @Configuration
    //@ImportResource(value = {"path/to/resource.xml"}) if you need to load additional xml configuration
    static class TestConfig {
       @Bean
       public BottleCounter bottleCounter() {
        return Mockito.mock(BottleCounter.class);
       }

       @Bean
       public Room room(BottleCounter bottleCounter) {
         Room room = new Room();
         room.setBottleCounter(bottleCounter);
         //r.setNumBottles(3); if you need 3 in each test
         return room;           
       }
    }

    @Autowired
    private Room room;  //room defined in configuration with mocked bottlecounter

    @Test
    public void testThreeBottlesAreSeperatedByNewLines()
    {
        Mockito.when(b.countBottle(Mockito.anyInt())).thenReturn("a");
        r.setNumBottles(3);
        assertEquals("a\na\na\na\n", r.generatePoem());
    }

}

OriginalL'auteur Nenad Bozic

Je suppose, ce n'est pas la bonne façon de tests Junit dans le Printemps de la création de la Salle de l'objet en utilisant le nouveau mot-clé dans votre RoomTest.java .

Vous pouvez utiliser le même fichier de configuration, j'.e Beans.xml fichier pour créer bean cours de test Junit cas.

Printemps @RunWith et @ContextConfiguration pour effectuer la tâche ci-dessus. Vérifier ici pour plus de détails explication.

OriginalL'auteur Waheed

D'abord une réponse

Vous devez exécuter votre test avec un Ressort de lanceur de test, à l'aide d'un test contexte spécifique

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:test-context.xml")

Laissez Printemps instancier votre bean, mais d'adapter votre test contexte spécifique de sorte qu'il exclut tous les haricots que vous n'avez pas besoin à l'intérieur d'un test, ou une maquette de suite les choses que vous ne voulez pas tester (par exemple, votre BottleCounter), mais ne peut pas exclure

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <!--Mock BottleCounter -->
    <bean id="myBottleCounter" name="myBottleCounter" class="org.mockito.Mockito" factory-method="mock">
        <constructor-arg value="org.world.hello.BottleCounter"/>
    </bean>

   <bean id="myRoom" class="org.world.hello.Room">
       <property name="bottleCounter" ref="myBottleCounter"></property>
       <property name = "numBottles" value = "10"></property>
   </bean>
</beans>

et une autre note, dans la production, vous aurez plus de chances de finir avec annoté les haricots qui sont captés par le printemps basé sur la numérisation du classpath pour annoté classes que s'opposer à la déclaration de tous en xml. Dans cette configuration, vous pouvez toujours se moquer de vos haricots avec une aide de context:exclude-filter, quelque chose comme

<!--Mock BottleCounter -->
<bean id="myBottleCounter" name="myBottleCounter" class="org.mockito.Mockito" factory-method="mock">
   <constructor-arg value="org.world.hello.BottleCounter"/>
</bean>
<context:component-scan base-package="org.world.hello">
   <context:exclude-filter type="regex" expression="org\.world\.hello\.Bottle*"/>
</context:component-scan>

Plus au sujet de votre dilemme

À mon avis vous avez défini le contexte d'un dilemme faux. Quand vous dites ai-je raison de comprendre que lors de l'utilisation de Printemps, vous devez utiliser le Printemps de configuration xml pour instancier des objets pour la production, et directement instancier des objets lors de l'essai de. Il ne peut y avoir qu'une seule réponse, oui, vous avez tort, parce que ce n'est pas lié à de Printemps à tous.

Le contexte où votre dilemme est valide, c'est quand vous avez raison à propos de l'intégration vs tests unitaires. En particulier, si vous définissez l'unité de test est le test d'un composant individuel avec tout le reste (y compris les dépendances à d'autres haricots) être moqué ou supprimée loin. Donc, si votre intention est d'écrire le test de l'unité selon cette définition, votre code est tout à fait normal, et même souhaitable cause par l'instanciation de l'objet directement, pas de cadre sera en mesure d'injecter automatiquement ses dépendances. Selon cette définition printemps tests sont des tests d'intégration, et c'est ce que @Koitoer mentionne dans sa réponse quand il dit , Vous appelez votre vrai haricots et qui ne sera pas un test unitaire, il sera plus comme des tests d'intégration

Dans la pratique, les gens ne sont généralement pas concernés à propos de la distinction. Le printemps se réfère à son test de tests unitaires. Le cas le plus courant est ce que @Nenad Bozic appelle une approche hybride, où vous voulez ot se moquer un peu de l'objet, par exemple de connexion à une base de données ou similaires, et sur la base de certains de vos commentaires c'est ce que vous avez besoin.

OriginalL'auteur Master Slave