2009-11-09 4 views
1

Nous avons une application J2EE basée sur Spring + Ibatis. Je prévoyais de boucler nos DAO (qui appellent les modèles iBatis ... en obtenant des haricots de printemps) avec des cas de test. Je n'ai pas beaucoup d'expérience avec JUnit donc j'ai pensé que faire simplement un objet de mon DAO et ensuite appeler l'une des méthodes fonctionnera. Mais je me trompais, il s'avère que toute l'application J2EE s'exécute sur appserver (conteneur), mais évidemment les cas de test JUnit sont en dehors du conteneur. Donc, dans mon cas de test, quand je fais l'objet de la dao et appeler une méthode ... il échoue sur une ligne comme celle qui est dans ma méthode DAOCette formation de printemps est-elle utile?

ApplicationInitializer.getApplicationContext().getBean("myMapclientBean"); 

Alors je suis allé à la chasse Google .. .commencé à travers certains messages et en suivant les tubes je me suis retrouvé sur 4 day training course de printemps.

Vous vouliez avoir votre avis sur ce que vous pensez de ce cours? Est-ce précieux pour le prix? Et une personne peut-elle apprendre ce genre de choses par elle-même? En suivant quelques livres? (Peut-être pas dans 4 jours mais, disons, plus d'un mois).

oh, et je ne suis toujours pas en mesure de tests unitaires ces DAO est ...> _ <

+0

Si vous touchez une base de données dans vos tests, ce n'est pas un test unitaire; c'est un test d'intégration. Maintenant, il est parfaitement possible d'utiliser JUnit pour effectuer des tests d'intégration, mais vous devez être conscient de la différence. Spring fournit un support de tests d'intégration pour JUnit et TestNG - consultez le manuel de référence. – SteveD

+0

merci. sachant que la différence m'aidera également dans les recherches sur google. – Drake

+0

Vous voudrez peut-être ouvrir une nouvelle question pour traiter la question de test unitaire. Vous pourriez obtenir de meilleures réponses de cette façon, car celle-ci est vraiment plus sur le cours Core Spring. – Jeff

Répondre

5

Je pris au cours du printemps de base il y a environ un an et demi. Le programme a apparemment changé un peu depuis lors, bien qu'il soit encore très similaire. L'instructeur était très compétent. Je travaillais avec Spring avant de suivre ce cours, mais dans la classe, j'ai l'impression d'avoir appris à faire les choses encore mieux.

Je pense que vous pouvez probablement obtenir toutes les informations brutes sur les livres, la documentation en ligne de Spring et le code source lui-même, mais ce que la classe fait, c'est de tout relier et d'enseigner les meilleures pratiques. C'est-à-dire, non seulement "comment" mais aussi "pourquoi" et "quand" vous devriez utiliser telle ou telle caractéristique. C'est pourquoi j'ai senti que mes compétences s'amélioraient.

L'instructeur était heureux de répondre à des questions sur des questions spécifiques du monde réel au-delà du travail en classe. Ce serait donc une bonne idée de venir avec des questions.

Le cours n'est pas bon marché. Que cela vaille la peine ou non, cela dépend si vous faites bien avec les salles de classe par rapport à l'auto-enseignement et en utilisant les communautés en ligne et les pairs pour avoir cette impression des meilleures pratiques que les livres n'offrent tout simplement pas. Aussi, gardez à l'esprit que le printemps est en constante évolution. Bien que vous puissiez obtenir une bonne base de la classe, vous devrez toujours vous adapter aux nouvelles fonctionnalités (ou suivre un autre cours).

+1

Aussi pris le cours et je suis d'accord avec tout @Jeff dit. IMO ça valait le coup. –

+0

merci les gars. C'est utile. Je vais demander à ma petite entreprise et voir si elles sont prêtes .... ou je vais commencer à rôder autour de jobs.SO :). Depuis que vous avez suivi une formation, pouvez-vous me dire comment les Testcases fonctionneront si l'application J2EE fonctionne à l'intérieur d'un conteneur (serveur d'application). Je veux dire que toutes les sources de données et tous les éléments sont sur le serveur de l'application ... alors comment jUnit fonctionnera-t-il quand vos DAO obtiendront des sources de données du serveur d'applications? – Drake

+0

Votre description ressemble plus à un test d'intégration qu'à un test unitaire ... mais cela semble toujours être le cas lors du test de DAO et de bases de données. Vous pouvez regarder la classe AbstractTransactionalDataSourceSpringContextTests. Cela pourrait aussi être utile pour vous: http://iamjosh.wordpress.com/2007/12/11/unit-testing-dao-classes-with-junit-spring/ – Jeff

0

Pour résoudre le problème à la main:

Lors de l'utilisation du printemps, vos haricots ne devraient pas vraiment aller à la ApplicationContext et demander les haricots dont ils ont besoin - ils doivent fournir setters (ou constructeurs), de sorte que les dépendances peut être injecté.

Il semble que quiconque a conçu ces classes a fait le contraire de l'injection de dépendance.

+0

sous le capot ... le contexte est à venir comme ceci springContext = WebApplicationContextUtils .getWebApplicationContext (event.getServletContext()); pourriez-vous s'il vous plaît fournir un petit échantillon de la façon dont vous pensez qu'ils devraient être afin que les cas de test Junit seraient en mesure d'utiliser ces haricots à l'extérieur du récipient? – Drake

+0

Le tutoriel de Spring MVC, bien qu'il soit spécifique au framework MVC, est une excellente introduction à Spring, IMO. http://static.springframework.org/docs/Spring-MVC-step-by-step/ L'injection de dépendances signifie qu'une classe est * donnée *, ce sont ses dépendances, et non pas qu'elle sort et les trouve. –

1

En réponse à la deuxième partie de la question (je n'ai pas eu l'expérience du cours du printemps, donc je ne peux pas commenter). Vous pouvez utiliser un contexte d'application défini à partir des tests Junit, puis instancier les DAO comme vous le feriez dans le conteneur du serveur, en faisant étendre votre cas de test à AbstractTransactionalDataSourceSpringContextTests si vous utilisez Junit 3.8 ou plus ancien.

Si vous utilisez des versions ultérieures de Junit (4+), vous pouvez utiliser le framework Spring TestContext et les annotations.

ont tous deux expliqué beaucoup mieux que je peux ici de Spring et sur cette annotations RefCard

+0

-1 - AbstractTransactionalDataSourceSpringContextTests est un avortement. Ainsi, une grande partie des extensions de cas de test fournies par Spring. AbstractSingleSpringContextTests est l'endroit où vous devriez cesser de les utiliser - ils deviennent de plus en plus horribles après ce point. – MetroidFan2002

+0

C'est sûr une opinion. Juste en montrant les options, le gars posant la question peut alors trouver sa propre façon de faire avancer les choses. – TomY

+0

J'ai utilisé la route AbstractTransactionalDataSourceSpringContextTests. travaille pour moi. J'ai instancié des junjis pour le projet d'accès à distance que nous avons au travail et cela constitue la base de nos tests de junit. via public class TestBase extends AbstractDependencyInjectionSpringContextTests

0

J'ai utilisé la route de AbstractTransactionalDataSourceSpringContextTests. travaille pour moi. J'ai instancié des junjis pour le projet d'accès à distance que nous avons au travail et cela constitue la base de nos tests de junit. via

import org.springframework.test.AbstractDependencyInjectionSpringContextTests; 
public class TestBase extends AbstractDependencyInjectionSpringContextTests 
{ 
    protected String[] getConfigLocations() 
    { 
    return new String[] { "classpath:conf/dataAccessContext.xml",  "classpath:conf/applicationContext-domain.xml", 
    "classpath:conf/applicationContext-service.xml", "classpath:conf/applicationContext-dao.xml" }; 
    } 

    protected Object getBeanToTest(String beanName) 
    { 
    return applicationContext.getBean(beanName); 
    } 

    protected Object getBeanToTest(Class clazz) 
    { 
    return applicationContext.getBean(clazz.getName()); 
    } 

}