Comment fait-on créer par programmation un Printemps contexte?

Personne ne sait si il existe un moyen de créer par programmation un haricot contexte?

Je veux être en mesure de faire quelque chose comme:

ConfigurableApplicationContext c = new ConfigurableApplicationContext();
BeanDefinition bd = new BeanDefinition();
bd.setId("id");
bd.setClassName("classname");
bd.setProperty("propertyName", propertyValue");
...etc...

ou, mieux encore, être capable d'injecter un haricot dans le contexte de l'application:

c.addBean("beanId", beanObject);

Ou si je suis en utilisant des annotations:

c.setAnnotationAware(true);
c.setAnnotationScanBasePackage("packagename");

c.addAnnotatedSpringClass("classnamethatisannotated");

La raison pour cela est que je veux être en mesure de remplacer bean définitions aux fins de tests - Dans mon test j'ai créer ce nouveau contexte d'application, configuré avec le code dans le test (pas en xml), et puis faire ce test de contexte de l'application en tant que parent le SUT contexte de l'application.

Je n'ai pas trouvé de code dans le printemps des bibliothèques qui peuvent le faire. Quelqu'un a construit quelque chose comme cela? Serait-il possible de construire quelque chose comme ça? Je sais que la première approche est faisable, je ne suis pas sûr à 100% la dernière approches seront sans conditions.

Est-il une raison de ne pas l'utiliser XML pour le test de haricots définitions? Spring fournit de l'unité de soutien d'essai exactement pour ce genre de chose.
Problème avec le xml, c'est que c'est un peu lourd. Prend trop de temps pour créer le xml et il semble un peu trop pour ce que vous essayez d'atteindre.
Bienvenue dans le monde de Java, mec.
Je pense que nous parlons des Tests d'Intégration, tests unitaires sont beaucoup plus simple 🙂

InformationsquelleAutor Michael Wiles | 2009-06-10

spring unit-testing

Essayer:

JavaConfig exemple de code

@Configuration
public class AppConfig {
    @Bean
    public TransferService transferService() {
        return new TransferServiceImpl();
    }
}

BeanBuilder exemple de code

def bb = new grails.spring.BeanBuilder()

bb.beans { 
  dataSource(BasicDataSource) { 
    driverClassName = "org.hsqldb.jdbcDriver" 
    url = "jdbc:hsqldb:mem:grailsDB" 
    username = "sa" 
    password = "" 
  } 

  sessionFactory(ConfigurableLocalSessionFactoryBean) { 
    dataSource = dataSource
    hibernateProperties = [ "hibernate.hbm2ddl.auto":"create-drop", "hibernate.show_sql":true ] 
  }   
}

AtUnit exemple de code

De test de l'unité

@RunWith(AtUnit.class)
@Container(Container.Option.SPRING)
@MockFramework(MockFramework.Option.EASYMOCK)
public class ExampleSpringEasyMockTest {

    @Bean @Unit UserManagerImpl manager;
    @Bean("fred") User fred;
    @Bean("userDao") @Mock UserDao dao;
    @Bean("log") @Stub Logger log;

    @Test
    public void testGetUser() {
        expect(dao.load(1)).andReturn(fred);
        replay(dao);
        assertSame(fred, manager.getUser(1));
        verify(dao);
    }


}

Fichier de contexte ( privé pour le test )

<?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-2.0.xsd">

  <bean id="userManager" class="atunit.example.subjects.UserManagerImpl">
      <constructor-arg ref="log"/>
      <property name="userDao" ref="userDao"/>
  </bean>

  <bean id="fred" class="atunit.example.subjects.User">
      <property name="id" value="500"/>
      <property name="username" value="fred"/>
  </bean>

</beans>

InformationsquelleAutor Robert Munteanu

4

Pourquoi ne pas simplement utiliser deux contextes différents? l'un pour la production, l'un pour les tests... vous allez sur ce dur chemin.

InformationsquelleAutor Chochos
4

Au Printemps, vous pouvez remplacer les haricots définition aussi facilement que pour les faire paraître encore plus bas dans le fichier. Nous utilisons beaucoup de très pour le but décrit; un autre bean définition pour les tests unitaires que pour la production.

C'est le modèle que nous utilisons pour nos test-context.xml
```
<import resource="classpath:production-context.xml">

<bean id="overriddenBean" class="com.MyClass">
   ....
</bean>
```
Cela signifie que le bean id = overriddenBean sera câblé dans les classes de votre production contewxts ont été référencé. Vous permettant de permuter les haricots vous avez besoin pour tester à la place de ceux que vous avez besoin pour la production de code.

Espère que cette aide

InformationsquelleAutor mR_fr0g

Il suffit d'ajouter une fève usine post-processeur qui permet de manipuler/ajouter les bean définition

    public class ABeanFactoryPostProcessor implements
        BeanFactoryPostProcessor {

    public void postProcessBeanFactory(
            ConfigurableListableBeanFactory beanFactory) throws BeansException {

            if (beanFactory instanceof BeanDefinitionRegistry) {
            BeanDefinition beanDefinition=...

                ((BeanDefinitionRegistry)beanFactory).registerBeanDefinition(name, beanDefinition);
            }
    }

}

bonne idée, n'aurait jamais pensé que.

InformationsquelleAutor Martin Ahrer

Il est de la marque nouvelle façon de ce faire - Printemps De Démarrage

import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;

@Configuration
@ComponentScan
@EnableAutoConfiguration
public class Application implements CommandLineRunner {

    private static final Logger LOG = LoggerFactory.getLogger(Application.class);

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        LOG.info("Hello world");
    }
}

InformationsquelleAutor MariuszS

Vous devez vous connecter pour publier un commentaire.