Je recherche des meilleures pratiques pour la mise en place de tests d'unité et d'intégration à l'aide du ressort.
J'utilise habituellement 3 types de tests: p>
Actuellement, je n'ai que des tests de la deuxième catégorie, qui est la partie délicate.
Je configurais une classe de test de base comme: p> et "unité" comme: p> avec attributs autonomes . P> Quelle est la meilleure façon d'exécuter le test dans un environnement différent (test d'intégration)? Sous-classe le test et remplacer le contexteConfiguration? P> @ContextConfiguration(locations = { "/my_spring_integration_test.xml" })
public class FooIntegrationTest extends FooTest
4 Réponses :
J'irais avec cette version: et dans Exemple pour JPA: P> my_spring_test.xml code>, j'utiliserais le PropertyPlaceholderConfigurier Code> Mécanisme . P> <plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<phase>pre-integration-test</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
new File(
pom.build.testOutputDirectory,
"test.properties"
).text = new File(
pom.basedir,
"src/main/config/int-test.properties"
).text;
</source>
</configuration>
</execution>
<execution>
<phase>generate-test-resources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
new File(
pom.build.testOutputDirectory,
"test.properties"
).text = new File(
pom.basedir,
"src/main/config/memory-test.properties"
).text;
</source>
</configuration>
</execution>
</executions>
</plugin>
Oui, j'utilise déjà la propriété-local et j'ai réfléchi à remplacer le fichier sur la classe de classe. Quel est le moyen le plus simple de le faire avec Maven? Des projets / dépendances séparés qui contiennent simplement un fichier de propriétés unique, puis modifier les dépendances en quelque sorte dépendant de la phase / du profil?
Merci, même si je ne veux pas introduire Groovy au projet à ce stade. Je pense que le problème est que Maven manque de support d'essai d'intégration approprié: willcode4beer.com/opinion. JSP? Set = Maven2_Integration-Test Je vérifierai si je peux le faire avec le branchement Mave-antrun ou même avec le plug-in Maven Resources (ressources: Copy-Ressources)
Vous n'introduisez pas Groovy au projet, en ajoutant juste deux lignes de Groovy à la construction. Votre projet n'aurait toujours aucune dépendance à Groovy au-delà de la construction (aucun pote n'a besoin d'être déployé). Même avec Antrun, votre projet n'aurait aucune dépendance à la fourmi.
Hmm, il semble que les deux réponses soient viables, mais une seule peut être sélectionnée comme bonne réponse ...?
@Puce choisir ou lancer une pièce de monnaie :-)
Oui, je sais, mais quelqu'un doit toujours maintenir le POM et le plus probablement que ce ne sera pas moi. Je suppose que davantage de personnes connaissent la fourmi qu'avec Groovy.
@Puce La bonne chose à propos de Groovy est que la source est compatible à 95% avec Java. Groovy = java + méthodes supplémentaires sur les classes JDK + du sucre syntaxique
J'ai étendu le GenericXmlContextLoader
et overrote les Méthode pour collecter les noms de fichier de configuration d'un répertoire que je peux spécifier par un systèmeProperty (-Dtest.config =). J'ai également modifié la méthode suivante pour ne pas modifier aucun emplacement i Utilisez ce chargeur de contexte comme celui-ci Exécution de l'essai avec une spécificité SystemProperty Indicateur de la source des fichiers de configuration vous permet maintenant d'utiliser des configurations complètement différentes. L'utilisation d'une SystemProperty n'est bien sûr qu'une seule stratégie pour spécifier l'emplacement de configuration . Vous pouvez faire tout ce que vous voulez dans Cette solution vous permet d'utiliser Complétez différentes configurations de contexte d'application (par exemple pour des objets simulés) et non seulement des propriétés différentes. Vous n'avez pas besoin d'une étape de construction pour tout déployer à votre emplacement "de classePath". Mon implémentation de béton a également utilisé le nom des utilisateurs par défaut pour rechercher un répertoire de configuration (SRC / test / ressources / {utilisateur}) Si aucune propriété système n'est donnée (facilite la maintenance d'environnements de test spécifiques pour tous les développeurs du projet). L'utilisation de la propriété propriétaire est toujours possible et recommandée. EDIT : Version printanière 3.1.0 Soutenir Profils XML / Abstraction d'environnement qui est similaire à ma solution et permettra le choix des fichiers de configuration pour différents environnements / profils. MyContextLoader public class {étend GenericXmlContextLoader protégées String [] generateDefaultLocations ( Classe CLZZZ) générationfaultlocations () .
Cela semble intéressant. Merci!
@Puce Regardez les nouvelles fonctionnalités de la prochaine version 3.1.0 (voir mon dernier édition).
Je n'ai eu aucun succès dans l'utilisation du contexte de printemps 3.x: étiquette de propriété-local. J'ai utilisé l'ancienne étiquette de haricot de mode avec un fichier de propriétés et j'ai pu configurer une connexion entre mon code et ma base de données, comme: Voici un exemple du fichier de propriétés: < / p> puis j'ai configuré mon test junit comme: qui a fonctionné pour moi, mais tout le monde fait des choses un peu différemment. J'espère que cela aide.
J'ai récemment couru dans le même problème et je regarde le documentation de l'annotation @contextConfiguration , j'ai remarqué l'option héritlocations em>. En ajoutant ceci à ma classe, par exemple p> @ContextConfiguration(locations = { "/my_spring_integration_test.xml" }, inheritLocations=false)
public class FooIntegrationTest extends FooTest
Avez-vous trouvé une solution qui convient à votre?