J'ai eu beaucoup de mal à essayer de trouver le meilleur moyen de suivre correctement les principes TDD tout en développant l'interface utilisateur en JavaScript. Quelle est la meilleure façon d'y parvenir?Développement de l'interface utilisateur en JavaScript à l'aide des principes TDD
Est-il préférable de séparer le visuel du fonctionnel? Développez-vous les éléments visuels en premier, puis écrivez des tests et ensuite codez pour la fonctionnalité?
J'ai fait quelques TDD avec Javascript dans le passé, et ce que je devais faire était faire la distinction entre les tests unitaires et d'intégration.Selenium va tester votre site global, avec la sortie du serveur, ses post-retours, les appels ajax, tout ça. Mais pour les tests unitaires, rien de tout cela n'est important.
Ce que vous voulez, c'est juste l'interface utilisateur avec laquelle vous allez interagir, et votre script. L'outil que vous utiliserez pour cela est JsUnit, qui prend un document HTML, avec des fonctions Javascript sur la page et les exécute dans le contexte de la page. Donc, ce que vous allez faire est d'inclure le HTML extensible sur la page avec vos fonctions. À partir de là, vous pouvez tester l'interaction de votre script avec les composants de l'interface utilisateur dans l'unité isolée du code HTML, votre script et vos tests.
Cela peut être un peu déroutant alors voyons si nous pouvons faire un petit test. Permet à certains TDD de supposer qu'après le chargement d'un composant, une liste d'éléments est colorée en fonction du contenu de l'objet LI.
tests.html
<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
<ul id="mockList">
<li>red</li>
<li>green</li>
</ul>
</body>
<script>
function testListColor() {
assertNotEqual($$("#mockList li")[0].getStyle("background-color", "red"));
var colorInst = new ColorCtrl("mockList");
assertEqual($$("#mockList li")[0].getStyle("background-color", "red"));
}
</script>
</html>
Il est évident que TDD est un processus en plusieurs étapes, donc pour notre contrôle, nous aurons besoin de plusieurs exemples.
yourcontrol.js (étape 1)
function ColorCtrl(id) {
/* Fail! */
}
yourcontrol.js (étape 2)
function ColorCtrl(id) {
$$("#mockList li").forEach(function(item, index) {
item.setStyle("backgrond-color", item.getText());
});
/* Success! */
}
Vous pouvez probablement voir le point de la douleur ici, vous devez garder votre code HTML maquette ici sur la page en synchronisation avec la structure de ce que seront vos contrôles serveur. Mais vous obtenez un bon système pour TDD avec JavaScript.
C'est la principale raison pour laquelle je suis passé à Google Web Toolkit ... Je développe et teste en Java et je m'attends raisonnablement à ce que le JavaScript compilé fonctionne correctement sur une variété de navigateurs. Puisque le TDD est principalement une fonction de test unitaire, la majeure partie du projet peut être développée et testée avant la compilation et le déploiement. Les suites d'intégration et de test fonctionnel vérifient que le code résultant fonctionne comme prévu après son déploiement sur un serveur de test.
Je n'ai jamais réussi à TDDed code UI. Le plus proche, nous sommes venus était en effet de séparer le code de l'interface utilisateur autant que possible de la logique de l'application. C'est l'une des raisons pour lesquelles le modèle modèle-vue-contrôleur est utile - le modèle et le contrôleur peuvent être TDD sans trop de problèmes et sans être trop compliqués. Dans mon expérience, la vue était toujours laissée pour nos tests d'acceptation par les utilisateurs (nous avons écrit des applications web et nos UAT utilisaient le HttpUnit de Java). Cependant, à ce niveau, c'est vraiment un test d'intégration, sans la propriété test-in-isolation que nous désirons avec TDD. En raison de cette configuration, nous avons d'abord écrit notre contrôleur/modèle de tests/code, puis l'interface utilisateur et UAT correspondant. Cependant, dans le code de l'interface graphique Swing que j'ai écrit récemment, j'ai d'abord écrit le code de l'interface graphique avec des stubs pour explorer la conception de l'interface avant de l'ajouter au contrôleur/modèle/API. YMMV ici cependant. Pour réitérer, le seul conseil que je peux donner est ce que vous semblez déjà soupçonner: séparer autant que possible votre code d'interface de votre logique et les traiter par TDD.
Je suis sur le point de commencer à faire du Javascript TDD sur un nouveau projet sur lequel je travaille. Mon plan actuel est d'utiliser qunit pour faire les tests unitaires. Pendant le développement des tests, vous pouvez simplement actualiser la page de test dans un navigateur.
Pour une intégration continue (et l'exécution des tests dans tous les navigateurs), je vais utiliser Selenium pour charger automatiquement le faisceau de test dans chaque navigateur et lire le résultat. Ces tests seront exécutés à chaque vérification du contrôle de la source.
Je vais également utiliser JSCoverage pour obtenir une analyse de couverture de code des tests. Cela sera également automatisé avec Selenium.
Je suis actuellement en train de mettre cela en place. Je mettrai à jour cette réponse avec des détails plus précis une fois que la configuration sera terminée.
Outils de test:
Voir aussi: JavaScript unit test tools for TDD
J'ai trouvé l'architecture MVP être très approprié pour l'écriture testable UIs. Votre Presenter et Le modèle peut simplement être testé à 100%. Il vous suffit de vous soucier de la Voir (qui devrait être une couche stupide, mince seulement déclenche des événements au présentateur) pour les tests de l'interface utilisateur (avec Sélénium etc.)
Notez que dans le je parle en utilisant MVP entièrement dans le contexte de l'interface utilisateur, sans nécessairement passer du côté serveur. Votre interface utilisateur peut avoir son propre présentateur et modèle qui vit entièrement du côté client. Le présentateur pilote la logique d'interaction/de validation de l'interface utilisateur, etc., tandis que le modèle conserve les informations d'état et fournit un portail au backend (où vous pouvez avoir un modèle séparé).
Vous devriez également jeter un oeil à la technique Presenter First TDD.
Ce que je fais est de piquer le Dom pour voir si je reçois ce que je m'attends. Un grand effet secondaire de ceci est qu'en rendant vos tests rapides, vous faites également votre application rapidement.
Je viens de publier une boîte à outils open source qui aidera énormément avec JavaScript tdd. C'est une composition de beaucoup d'outils open source qui vous donne une application de backbone exigeante de travail hors de la boîte.
Il fournit des commandes uniques à exécuter: serveur web dev, lanceur de test de navigateur unique jasmine, lanceur de test multi-navigateur jasmine js-test-driver, et concaténisation/minimisation pour JavaScript et CSS.Il génère également une version non -minimalisée de votre application pour le débogage de production, précompile les modèles de guidon et prend en charge l'internationalisation.
Aucune configuration n'est requise. Cela fonctionne juste.