Discussion :

[yyusy]

Bonjour,

Voila je réalise des tests unitaires sur une application qui communique avec une base de données.
Lors de l'exécution des tests unitaires j'aimerais ne pas communiquer avec ma vraie base (base 1) mais une autre base de données (base 2) pour éviter de polluer la principale.

J'ai vue que Spring permet de gérer des contextes et donc de ne pas avoir à changer la configuration de config.xml mais je ne sais pas comment le mettre en œuvre.

Si quelqu'un connait une site ou un tutoriel qui explique comment gérer les contextes ou qu'il veut bien m'expliquer.

Merci

Quelques precisions
Actuellement dans le fichier de configuration de spring j’ai un bean pour communiquer avec la base de données :
<bean id= « totoDao » class= « org.dao.totoDaoJdbc »>
<constructor-arg index= « 0 » value= «driver »>
<constructor-arg index= « 0 » value= «url »>
<constructor-arg index= « 0 » value= «login »>
<constructor-arg index= « 0 » value= «password »>
< /bean>

[Hikage]

Hello,

Alors tout d'abord, si je puis me permettre, je te conseille de regarder du coté de AbstractTransactionalDataSourceSpringContextTests, qui permet de faire des tests d'accès DB dans un mode transactionnel, et donc de ne pas réellement polluer la DB.

Sinon, pour les fichiers, ce que je peux te conseiller c'est d'avoir plusieurs fichier :

• service-config.xml
• datasource-config.xml, dans lequel tu définis ta DataSource
• ...

Et pour ton contexte Spring, de charger le tout.
Dès lors, il te suffira dans tes tests de charger tout les fichiers, sauf datasource-config que tu remplacera par datasource-test-config.xml

[yyusy]

Merci de ta réponse en effet la classe AbstractTransactionalDataSourceSpringContextTests peut répondre à mon besoin mais le problème est que souvent lors des phases de développement nous n’avons pas accès à la base de données car elle peut être hébergée chez le client.

J'ai trouvé un objet ListableBeanFactory. Avec deux fichier de configuration un pour ma base réelle et un pour ma base de tests puis-je faire cela ???

public class Tests extends TestCase {
// usine à beans
private ListableBeanFactory bfactory;
// init tests
public void setUp() {
bfactory = new XmlBeanFactory(new ClassPathResource("BD-config.xml"));
// bfactory = new XmlBeanFactory(new ClassPathResource("BD-test-config.xml"));
}

Et sinon dans le même fichier de configuration mais en définissant 2 beans

<beans>
<bean id="BD-test" class="…... "init-method="init" destroy-method="close">
<constructor-arg index="0"><value>org.firebirdsql.jdbc.FBDriver</value>
</constructor-arg>
<constructor-arg index="1"><value>jdbc:firebirdsql:localhost/3000:d:/db1.gdb</value>
</constructor-arg>
<constructor-arg index="2"><value>Admin</value></constructor-arg>
<constructor-arg index="3"><value>Azerty_1</value></constructor-arg>
</bean>

<bean id="BD" class="……"init-method="init" destroy-method="close">
<constructor-arg index="0"><value>org.firebirdsql.jdbc.FBDriver</value>
</constructor-arg>
<constructor-arg index="1"><value>jdbc:firebirdsql:localhost/3000:d:/db2.gdb</value>
</constructor-arg>
<constructor-arg index="2"><value>Admin</value></constructor-arg>
<constructor-arg index="3"><value>Azerty_1</value></constructor-arg>
</bean>
</beans>

Ensuite exécute la méthode getBean avec comme paramètre l’Identifiant du bean déclaré dans le fichier de configuration lorsque l'on désire l'information.

bfactory.getBean("BD-test");
// bfactory.getBean("BD ");

Cela peut-il fonctionner ???

[JeitEmgie]

Vous avez une méthode dans les classes de or.springframework.test.* :

String[] getConfigLocations()

que vous pouvez "overrider" dans votre propre sous-classe pour spécifier le(s) fichier(s) de configuration correspondant à votre situation client…