2010-11-28 5 views
5

J'ai écrit du code piloté par les tests avant même de comprendre ce que TDD était réellement. Appeler des fonctions et des classes sans avoir sa mise en œuvre m'aide à comprendre et à construire mon application de manière beaucoup plus rapide et efficace. Je suis donc très habitué au processus d'écriture du code -> le compiler -> le voir échouer -> le corriger en construisant son implémentation.Développement basé sur les tests pour les JSP spécifiquement

Ce processus est un peu plus difficile pour le Web. Plus précisément les JSP. Quand je compile mes classes Java, tout va bien, je peux voir les erreurs de compilation. Cependant, en voyant des erreurs dans les pages JSP, vous devez ouvrir un navigateur et appeler cette page JSP spécifique.

Y at-il un moyen d'éviter ce processus et de me montrer les erreurs de compilation JSP sans réellement charger un navigateur?

Répondre

2

Je ne teste généralement pas les JSP directement. C'est généralement une bonne idée de garder le moins de logique possible dans vos JSP, et si vos JSP contiennent seulement quelques balises <c:out> alors il n'y a pas vraiment trop de choses à tester. Cependant, si vous avez une bonne quantité de logique, alors ce que je ferais est d'extraire cette logique dans une étiquette personnalisée, que vous pouvez tester assez facilement.

+0

vous avez raison ... jsps ne devrait pas contenir de logique en premier lieu –

3

Bien sûr. Vous pouvez pré-compiler JSP. Il y a même une tâche de fourmi qui le fait. S'il vous plaît se référer au lien: http://ant.apache.org/manual/Tasks/jspc.html

Mais je pense que ce n'est que le premier pas. Cela vous permettra de voir les erreurs de compilation. Je pense que vous vouliez plus, c'est-à-dire des tests unitaires. Je crois que des outils comme Jakarta Cactus (ou d'autres) peuvent vous aider.

BTW récemment, j'ai trouvé le suivant resource qui énumère un grand nombre d'outils de test de Java.

+0

+1 JspC n'est pas seulement une tâche ant, c'est un shell pour le compilateur de servlets JSP-> intégré à Tomcat, que vous pouvez utiliser dans n'importe quel environnement de construction. @Luca: Même si vous n'utilisez pas Tomcat comme serveur JEE, il pourrait bien être un outil pratique dans votre processus: http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/jasper /JspC.html –

+0

"2011/08/05 - Jakarta Cactus a pris sa retraite." – Raedwald

1

La compilation est la partie facile, et je pense que la réponse d'AlexR est très bien. Le test et la conduite de tests JSP est difficile, car les tests nécessitent un déploiement sur un conteneur Web ou une simulation (simulacre) de celui-ci, et un navigateur ou quelque chose ressemblant à un navigateur.

Cactus peut aider avec les tests en conteneur. Selenium peut aussi bien.

Ou vous pouvez simuler l'environnement. Si vous utilisez Spring, il a un bon support pour le faire. Mais la meilleure façon de faire face à la difficulté de tester et de piloter les tests JSP est d'arrêter complètement d'utiliser JSP, ou au moins de minimiser la logique dans votre code JSP en évitant les scriptlets.

Comme une JSP est juste un servlet déguisé, il est toujours possible d'écrire des applications Web sans JSP, et il y a des options à l'aide des cadres comme Wicket et Tapestry ou moteurs modèle comme Velocity pour faire du développement d'applications Java Web sans JSP assez facile.

Questions connexes