Produits complémentaires

et les polices.
Les développeurs chevronnés en programmation
se sentiront peut-être
plus à  l’aise avec un éditeur à  base de
texte qui vérifie la syntaxe de chaque
langage de programmation. Les programmeurs
auront toujours besoin
d’accéder au code source à  un certain
point du processus de développement,
tandis que les concepteurs graphiques
n’auront peut-être nul besoin
de manipuler le code directement. Les
développeurs responsables d’une
gamme de composants utilisant des
technologies différentes (JSP, Java
beans, par exemple), préfèreront probablement
un environnement intégré
acceptant toutes les technologies
qu’ils utilisent.

Quel que soit l’outil sélectionné, il
convient d’évaluer les fonctions de
gestion du changement et de test.
Quand de multiples développeurs travaillent
sur des composants séparés
d’un projet (peut-être avec des technologies
différentes et des outils de développement
différents), ce n’est pas
une sinécure que de suivre tous les
composants, qui est responsable de chacun, et quand ils seront prêts pour
le test d’intégration.

Le support du test va des outils de
debugging à  la maintenance d’un environnement
de test complètement séparé.
Comme il n’est pas simple d’optimiser
l’exécution de WAS, la plupart
des développeurs préfèrent utiliser un
environnement serveur d’applications
Web plus simple pour le test (pour en
savoir plus sur la configuration WAS,
voir l’article « Vos premiers pas comme
administrateur de WAS »).

Les options disponibles pour l’environnement
de test dépendent des
services WAS précis que vous envisagez
d’utiliser dans votre application définitive.
Et l’expérience des développeurs
influence souvent le choix de la solution.
La plupart des outils de développement
Java, par exemple, incluent
des environnements de test pour les
servlets. Vous pouvez aussi charger de
simples exécuteurs de servlets comme
JRun de Macromedia. Bien que les EJB
puissent être testés en dehors de WAS,
il y a moins d’alternatives que pour les
servlets et les JSP.