Testen Ihres Codes

ReneRubalcava

<\/HEAD>

<\/P>

Du schreibst badass Apps<\/STRONG><\/EM>. Deine Nutzer sind glücklich, du bist glücklich, alles ist rosig<\/EM>. Jemand sagt, er möchte neue Features. Du denkst dir rad dude, ich hab das<\/EM>. Du fängst an zu schreiben und zu refaktorisieren, fügst neue Module hinzu, passt ein paar andere an und irgendwo unterwegs stürzt deine gesamte Anwendung ab. Etwas ist kaputt gegangen und du hast so viele Änderungen gemacht, dass du nicht mehr sagen kannst, was wo kaputt gegangen ist.<\/P><\/P>Du bist sowas von am Arsch.<\/STRONG><\/P><\/P>Vielleicht warst du nie in so einer schlimmen Situation, aber ich wette, du hast schon hässliche Sachen in deinem Code machen müssen, um Dinge zum Laufen zu bringen, weil du ein seltsames Problem umgehen musstest, das beim Hinzufügen neuer Features aufgetaucht ist.<\/P><\/P>Die Scham<\/H2>Als Entwickler fühlen wir uns alle so, als sollten wir es tun. Vielleicht starten wir ein neues Projekt mit Begeisterung und tun es. Wir sollten unseren Code testen. Ich bin schuldig, ein Projekt mit vielen Tests gestartet zu haben, aber irgendwo unterwegs habe ich es nicht durchgehalten und fühle mich schrecklich deswegen. Aber es muss nicht so sein. Unit tests<\/A> sind für große Projekte angemessen, vertrau mir. Vielleicht ist es TDD<\/A> oder BDD<\/A> oder du schreibst Tests einfach nachträglich. Wie auch immer du es machst, du wirst dir später nur danken, wenn ein Projekt wächst.<\/P>

<\/P>

Hier ist ein

Repo zum Testen<\/A> von früheren Esri Dev Summits und ein cooles Karma Beispiel<\/A>. Ich mag Karma, es ist ein cooler Test Runner, aber kürzlich habe ich TheIntern<\/A> zum Testen wiederentdeckt. Intern ist wirklich cool und man kann einige wirklich grodfe Posts auf SitePen<\/A> darfcber lesen. Schau dir den fcber InternRecorder an<\/A>, der ist fantastisch.<\/P>

<\/P>

Vereinfache deinen Ablauf<\/H2>Der einzige Nachteil von Intern gegenfcber etwas wie Karma, das ich nie zum Laufen gebracht habe, ist, meine Tests im Terminal bei jeder Dateie4nderung auszuffchren, aber ich habe das mit live-reload<\/A> in meinem Entwicklungstoolkit umgangen.<\/P>

<\/P>

Kombiniere live-reload mit

Grunt<\/A> und ein paar Plugins und jedes Mal wenn ich eine c4nderung an meiner App mache, wird meine App im Browser neu geladen und meine Testseite wird ebenfalls neu geladen, sodass ich sofort sehen kann, ob ich etwas kaputt gemacht habe.<\/P>

<\/P>

<\/P>

<\/P>

Grün ist eine wunderschöne Farbe.<\/P>

<\/P>

Jetzt werde ich nicht auf das ganze

rot/grün/refactor<\/A>-Ding von tdd oder Unit Testing eingehen. Es gibt viele Tutorials da draußen, die dir dabei helfen kf6nnen. Es gibt auch eine ganze Welt da draußen fcber Spies und Mocks zum Testen. Ich sage nur, dass ich SinonJS<\/A> ffcr diesen Zweck mag. Ich kenne es und bin daran gewf6hnt, aber andere haben vielleicht andere Vorlieben.<\/P>

<\\/p>

Also wie sieht ein Beispieltest aus? Vielleicht so.<\\/p>

define(function(require) {\n  var registerSuite = require('intern!object');\n  var expect = require('intern\\chai!expect');\n  var View = require('app\\components\\map\\WebMapView');\n  var topic = require('dojo\\topic');\n  var config = require('app\\config');\n  var utils = require('esri\\arcgis\\utils');\n  var chai = require('intern\\chai!');\n  var sinon = require('sinon');\n  var sinonChai = require('sinon-chai');\n  chai.use(sinonChai);\n  var mapView;\n  registerSuite({\n    name: 'components: WebMapView',\n    setup: function() {\n      \/\/- set up test here\n      sinon.stub(utils, 'createMap').returns({\n        then: function(){}\n      });\n    },\n    beforeEach: function() {\n      \/\/- run before\n    },\n    afterEach: function() {\n      \/\/- run after\n      if (mapView &; mapView.destroy) {\n  &m... (truncated due to length)}}  b. Das ist alles. Es ist also eine gute Methode, schnell festzuhalten, was Sie erreichen wollen. Wenn Sie die Tests nachträglich schreiben, laufen Sie Gefahr, die Tests so zu schreiben, dass sie zu Ihrem Code passen, der möglicherweise fehlerhaft ist. ABER, wenn Sie diese Tests erneut ausführen, während Sie mehr Code schreiben, wissen Sie zumindest, ob Sie etwas kaputt gemacht haben, das zuvor funktionierte.Es gibt viele Ressourcen zum JavaScript-Testing. Hier sind ein paar, an die ich denken kann.

Einführung in JavaScript Unit TestingJavaScript Testing RecipesIntern Tutorial esri jsapiHier ist ein Demo-Projekt, das Testing und Grunt-Tools enthält, um Ihnen zu helfen.Für weitere Geodev-Tipps und Tricks, sehen Sie sich meinen Blog an.