Tester votre code

ReneRubalcava

<\/HEAD>

<\/P>

Vous écrivez des applications badass<\/STRONG><\/EM>. Vos utilisateurs sont heureux, vous êtes heureux, tout est parfait<\/EM>. Quelqu'un dit qu'il veut de nouvelles fonctionnalités. Vous êtes comme super mec, je gère ça<\/EM>. Vous commencez à écrire et refactoriser, ajouter de nouveaux modules, ajuster quelques autres et quelque part en cours de route toute votre application s'effondre. Quelque chose a cassé et vous avez fait tellement de changements que vous ne pouvez pas dire ce qui a cassé où.<\/P><\/P>Vous êtes vraiment dans la merde.<\/STRONG><\/P><\/P>Peut-être que vous n'avez jamais été dans un scénario aussi horrible, mais je parie que vous avez dû faire des trucs moches dans votre code pour que ça fonctionne parce que vous deviez contourner un problème bizarre qui est apparu en ajoutant de nouvelles fonctionnalités.<\/P><\/P>La honte<\/H2>En tant que développeurs, nous avons tous l'impression que nous devrions le faire. Peut-être que nous commençons un nouveau projet avec enthousiasme en le faisant. Nous devrions tester notre code. Je suis coupable d'avoir commencé un projet avec beaucoup de tests, mais quelque part en cours de route je ne continue pas et je me sens horrible à ce sujet. Mais ça ne doit pas être comme ça. Les tests unitaires<\/A> sont appropriés pour les grands projets, croyez-moi. Peut-être que c'est TDD<\/A> ou BDD<\/A> ou vous écrivez simplement des tests après coup. Quelle que soit la manière dont vous le faites, vous ne pourrez que vous remercier plus tard à mesure qu'un projet grandit.<\/P>

<\/P>

Voici un

dépôt sur les tests<\/A> issu des précédents Esri Dev Summits et un super exemple Karma<\/A>. J'aime Karma, c'est un super lanceur de tests, mais récemment j'ai revisité TheIntern<\/A> pour les tests. Intern est vraiment cool et vous pouvez lire quelques excellents articles sur SitePen<\/A> à son sujet. Découvrez celui sur InternRecorder<\/A> qui est génial.<\/P>

<\/P>

Simplifiez votre flux<\/H2>Le seul inconvénient d'Intern par rapport à quelque chose comme Karma que je n'ai jamais réussi à faire fonctionner est de faire exécuter mes tests dans le terminal à chaque changement de fichier, mais j'ai contourné cela en utilisant live-reload<\/A> dans ma boîte à outils de développement.<\/P>

<\/P>

Combinez live-reload avec

Grunt<\/A> et quelques plugins et chaque fois que je fais un changement dans mon application, mon application se recharge dans le navigateur et ma page de test se recharge aussi pour que je puisse voir instantanément si j'ai cassé quelque chose.<\/P>

<\/P>

<\/P>

<\/P>

Le vert est une belle couleur.<\/P>

<\/P>

Maintenant, je ne vais pas entrer dans tout le concept

rouge\vert\refactor<\/A> du tdd ou des tests unitaires. Il y a plein de tutoriels pour vous aider là-dessus. Il y a aussi tout un monde autour des espions et mocks pour les tests. Je dirai juste que j'aime b. C'est tout. C'est donc un bon moyen de noter rapidement ce que vous essayez d'accomplir. Si vous écrivez les tests après coup, vous prenez le risque d'écrire les tests pour correspondre à votre code, qui pourrait être défectueux. MAIS, si vous relancez ces tests au fur et à mesure que vous écrivez plus de code, vous saurez au moins si vous avez cassé quelque chose qui fonctionnait auparavant.

Il existe de nombreuses ressources sur les tests JavaScript. En voici quelques-unes auxquelles je pense.

Introduction aux tests unitaires JavaScriptRecettes de tests JavaScriptTutoriel Intern esri jsapiVoici un projet de démonstration qui inclut des tests et des outils grunt pour vous aider.Pour plus d'astuces geodev, consultez mon blog.