Samarali test holatlarini yaratish turli sabablarga ko'ra ilova qismlarining xatti-harakatlari o'zgarishi mumkin bo'lgan yirik loyihalar uchun juda muhim bo'lishi mumkin. Ehtimol, eng keng tarqalgan muammo, ishlab chiquvchilarning katta guruhi bir xil yoki tegishli modullar ustida ishlayotganida. Bu boshqa dasturchilar tomonidan yozilgan funksiyalarning xatti-harakatlarida rejalashtirilmagan o'zgarishlarga olib kelishi mumkin. Yoki qat'iy belgilangan muddatlarda ishlash dasturning muhim qismlarini qasddan o'zgartirishga olib keladi.

Veb-ilovani sinovdan o'tkazish odatda sahifa elementlarini vizual baholashni va funksionallikning ishlashini empirik baholashni o'z ichiga oladi. Boshqacha qilib aytganda, bo'limlar bo'ylab harakatlanishda va dinamik elementlarda harakatlarni bajarishda.

Vaqt o'tishi bilan loyiha yangilari bilan to'ldiriladi funksionallik, bu uning ishlashini tekshirish jarayonini uzaytiradi va murakkablashtiradi. Avtomatlashtirish uchun birlik testi qo'llaniladi.

Sinov stsenariylarini yaratishda ikkita yondashuv mavjud:

• Whitebox testi - testlarni yozish funksionallikni amalga oshirishga asoslangan. Bular. Biz tizim modullarimiz ishi asoslangan bir xil algoritmlar yordamida tekshiramiz. Ushbu yondashuv umuman tizimning to'g'ri ishlashini kafolatlamaydi.
• Blackbox testi - skript yaratish tizim spetsifikatsiyalari va talablariga asoslanadi. Shu tarzda siz butun dastur natijalarining to'g'riligini tekshirishingiz mumkin, ammo bu yondashuv kichik va kam uchraydigan xatolarni qo'lga kiritishga imkon bermaydi.

Siz qo'llagan har bir xususiyatni sinab ko'rishga arziydigandek tuyulishi mumkin. Bu mutlaqo to'g'ri emas. Testlarni yozish ishlab chiquvchining vaqtini oladi, shuning uchun dasturni yaratish jarayonini optimallashtirish uchun testlarni faqat murakkab, muhim funktsiyalar uchun yoki boshqa tizim modullarining natijalariga bog'liq bo'lgan funktsiyalar uchun tayyorlashga arziydi. Noaniq mantiqni xatolarga olib kelishi mumkin bo'lgan testlar bilan yoping. Shuningdek, kelajakda optimallashtirish rejalashtirilgan kod bo'limlari uchun testlarni yaratishga arziydi, shunda optimallashtirish jarayonidan so'ng siz ularning to'g'ri bajarilganligini tekshirishingiz mumkin.

Umuman olganda, ishlab chiqish muddatlarining qat'iyligiga nisbatan sinov xarajatlarini baholash juda muhimdir. Albatta, agar siz vaqt bilan cheklanmagan bo'lsangiz, har bir funktsiyani testlar bilan qoplashga ruxsat berishingiz mumkin. Ammo, qoida tariqasida, ishlab chiqish qattiq vaqt bosimi ostida amalga oshiriladi, shuning uchun tahlilchi yoki tajribali ishlab chiquvchining vazifasi qaerda sinov zarurligini tushunishdir. Bundan tashqari, testlarni yozish loyiha narxini oshiradi.

Shunday qilib, birlik testidan foydalanish oqlangan bo'lsa, biz uchta holatni shakllantirishimiz mumkin:

1) Agar testlar xatolarni odatdagi qidiruvdan ko'ra tezroq aniqlashga imkon bersa.

2) Nosozliklarni tuzatish vaqtini qisqartiring

3) Tez-tez o'zgartirilgan kodni sinab ko'rish imkonini beradi.

Frontendning 3 ta asosiy komponentidan (HTML, CSS, JavaScript), ehtimol faqat JavaScript kodini sinab ko'rish kerak. CSS faqat tekshiriladi vizual usul, ishlab chiquvchi/sinovchi/mijoz GUI-ni turli brauzerlarda ko'rganda. HTML belgilash xuddi shu usul yordamida tekshiriladi.

Sinov stsenariylarini tuzishda siz quyidagi tamoyillarga amal qilishingiz kerak:

• Sizning testlaringiz iloji boricha sodda bo'lishi kerak. Keyin uni amalga oshirish natijalariga siz takrorlamoqchi bo'lgan xato ta'sir qilish ehtimoli ko'proq bo'ladi.
• Katta birlik testlarini parchalash. Xatoning aniq joyini topish yaxshiroqdir.
• Testlarni mustaqil qiling. Bir sinovning natijasi hech qanday tarzda boshqasining natijalariga bog'liq bo'lmasligi kerak.
• Sinov natijalari to'liq takrorlanadigan va kutilgan bo'lishi kerak. Har safar sinovni qaytadan o'tkazganingizda, natija oxirgi marta bo'lgani kabi bo'lishi kerak.
• Ilovani bajarishdagi har qanday xatolik uchun test skripti yaratilishi kerak. Shunday qilib, xato haqiqatan ham tuzatilganiga va foydalanuvchilarga ko'rinmasligiga ishonch hosil qilasiz.

Js kodini test qilish uchun bir nechta kutubxonalar mavjud. Ehtimol, eng keng tarqalgani QUnit. Ushbu kutubxona yordamida birlik testlarini o'tkazish uchun biz "qum qutisi" ni yaratishimiz kerak - oddiy HTML sahifasi, unda sinov uchun kutubxona, sinovdan o'tkazilishi kerak bo'lgan kod va testlarning o'zi ulanadi.

Sinovlar uchun funktsiyalar:

(function() ( window.stepen = function(int) ( var natija = 2; for (var i = 1; i)< int; i ++) { result = result * 2; } return result; } window.returnFunc = function() { return "ok"; } })();

Test ro'yxati:

Test("stepen()", function() ( teng(stepen(2), 4, "2^2 - teng usul"); ok(stepen(3) === 8, "2^3 - ok usuli" ); deepEqual(stepen(5), 32, "2^5 - deepEqual usuli"); )); asyncTest("returnFunc()", function() ( setTimeout(function() ( teng(returnFunc(), "ok", "Async Func Test"); start(); ), 1000); ));

Ko'rib turganingizdek, QUnit kodni bajarish natijalarini kutilganlar bilan taqqoslash uchun 3 ta funktsiyani qo'llab-quvvatlaydi:

• ok() - agar qaytarilgan natija = rost bo'lsa, testni muvaffaqiyatli deb hisoblaydi
• teng() - natijani kutilgan natija bilan solishtiradi
• deepEqual() - natijani kutilgan natija bilan solishtiradi, uning turini tekshiradi

Amalga oshirish natijasi:

Ko'rib turganingizdek, QUnit kutubxonasi bir vaqtning o'zida bir nechta brauzerlar uchun kodni sinab ko'radi.

Bir qator boshqa sinov kutubxonalari mavjud. Biroq, ulardagi test stsenariylarini qurish kontseptsiyasi bir xil, shuning uchun birini tushunganingizdan so'ng, boshqasiga o'tish siz uchun qiyin bo'lmaydi.

Zamonaviy JS kodining xususiyati uning asinxron bajarilishidir. Sinov kutubxonalari odatda asinxron testlarni o'tkazish imkoniyatiga ega. Ammo, masalan, agar siz backendga get so'rovini yuboradigan va undan javob qaytaradigan funktsiyani sinab ko'rmoqchi bo'lsangiz, testlarni o'tkazish uchun siz stop() funktsiyasi bilan ipni to'xtatishingiz kerak bo'ladi. funktsiyani sinab ko'ring va keyin setTimeout() da "o'rash" bilan start() usuli bilan ipni qayta ishga tushiring. Bular. funktsiya bajarilishini yakunlashi kerak bo'lgan ma'lum vaqtni belgilashingiz kerak. Ushbu segmentning davomiyligini diqqat bilan tanlashingiz kerak. bir tomondan uzoq ish Usul xususiyat yoki hatto dastur funksionalligini muayyan amalga oshirishga bo'lgan ehtiyoj yoki noto'g'ri xatti-harakatlar bo'lishi mumkin.

Backbone.js yordamida yozilgan ilovalarni sinovdan o'tkazish misoli uchun biz maqolada tasvirlangan loyihadan foydalanamiz.

Tekshirish uchun birlik testlaridan foydalanishingiz mumkin:

• Modellar va kontrollerlarni to'g'ri yaratish
• Modellardagi ma'lumotlarning to'g'riligi
• Tekshirish usullarini bajarish (buning uchun ular natijani qaytarishi kerak)
• Koʻrishlar yuklanmoqda

Test kodi:

Test("Backbone.js", function() ( ok(namuna, "Ismlar maydonini tekshirish"); ok(sample.routers.app, "Router tekshiruvi"); ok(sample.core.pageManager.open("chat") , "Sahifani ochish testi (Controller usuli chaqiruvi)") ok(sample.core.state, "Model tekshiruvi"); teng(sample.core.state.get("content"), "sintel", "Model ma'lumotlari testini olish "); stop(); ok(funksiya() ( $.ajax(( url: "app/shablonlar/about.tpl", dataType: "matn")). bajarildi(funksiya(ma'lumotlar) ( self.$el. html(ma'lumotlar); ma'lumotlarni qaytarish; )) ), "Shablonni yuklashni tekshirish"); setTimeout(funktsiya () ( start(); ), 1000); ));

Sinov xatolari bilan ishlash natijasi:

Odatda, dasturni o'rnatish intensiv rivojlanish jarayonida tez-tez bajarilishi kerak bo'lgan vazifadir. Shuning uchun bu operatsiya odatda avtomatlashtirilgan. Ishimizda biz Jenkins-dan, uzluksiz integratsiya uchun vositadan foydalanamiz. G'oya Jenkins orqali tarqatishni avtomatlashtirilgan testlar bilan birlashtirishdir.

QUnit testlari brauzerda ishlaydi. Phantomjs, brauzerning ishlashiga taqlid qiluvchi dasturiy ta'minot bizga bu xususiyatni aylanib o'tishga yordam beradi. Phantomjs ishlab chiquvchilari allaqachon QUnit testlarini bajarish uchun skriptni taqdim etishgan, ammo to'g'ri ishlashi uchun uni biroz o'zgartirish kerak edi.

/** * Sinov sharti to'g'ri bo'lguncha yoki kutish vaqti tugaguncha kuting. * Server javobida * kutish yoki foydalanuvchi interfeysi o'zgarishi (fadeIn va boshqalar) uchun foydalidir. * * @param testFx javascript sharti mantiqiy qiymatga baholanadi, * u satr sifatida uzatilishi mumkin (masalan: "1 == 1" yoki * "$("#bar").is(":visible)" yoki * qayta qo'ng'iroq qilish funksiyasi sifatida. * @param ontestFx sharti bajarilganda nima qilish kerak, * u satr sifatida uzatilishi mumkin (masalan: "1 == 1" yoki * "$("#bar").is ("#bar"). ":visible")" yoki * qayta qo'ng'iroq qilish funksiyasi sifatida. * @param timeOutMillis kutish uchun maksimal vaqt miqdori. Agar * ko'rsatilmagan bo'lsa, 3 soniya ishlatiladi. */ function waitFor(testFx, onReady, timeOutMillis) ( var maxtimeOutMillis = timeOutMillis? timeOutMillis: 3001, //< Default Max Timout is 3s start = new Date().getTime(), condition = false, interval = setInterval(function() { if ((new Date().getTime() - start < maxtimeOutMillis) && !condition) { // If not time-out yet and condition not yet fulfilled condition = (typeof(testFx) === "string" ? eval(testFx) : testFx()); //< defensive code } else { if(!condition) { // If condition still not fulfilled // (timeout but condition is "false") console.log(""waitFor()" timeout"); phantom.exit(1); } else { // Condition fulfilled (timeout and/or condition is //"true") console.log(""waitFor()" finished in " + (new Date().getTime() - start) + "ms."); typeof(onReady) === "string" ? eval(onReady) : onReady(); //< Do what it"s supposed to do once the // condition is fulfilled clearInterval(interval); //< Stop this interval } } }, 100); // repeat check every 250ms }; }; if (phantom.args.length === 0 || phantom.args.length >2) console.log("Foydalanish: run-qunit.js URL"); phantom.exit(); ) var page = new WebPage(); // Sahifa ichidan "console.log()" qo'ng'iroqlarini yo'naltiring // kontekstdan asosiy Phantom kontekstiga (ya'ni joriy "bu") page.onConsoleMessage = function(msg) ( console.log(msg); ); page.open(phantom.args, function(status)( if (status !== "muvaffaqiyat") ( console.log("Tarmoqqa kirish imkoni yo'q"); phantom.exit(); ) else ( waitFor(function()) ( return page.evaluate(function())( var el = document.getElementById("qunit-testresult"); if (el && el.innerText.match("completed")) ( return true; ) return false; )) ; ), function())( var failedNum = page.evaluate(function())( var el = document.getElementById("qunit-testresult"); console.log(el.innerText); urinib ko'ring ( return document.getElementsByClassName( "fail" ). innerHTML.length; ) catch (e) (qaytish 0; ) qaytish 10000; )); phantom.exit((parseInt(failedNum, 10) > 0) ? 1: 0); )); ) ) );

Natijalar haqidagi xabarlarni konsolga chiqarish uchun siz sinov skriptiga jurnalga yozish funksiyasini qo'shishingiz kerak.

Node.js da oddiy kalkulyator ilovasi misolidan foydalanish. Biz Mocha ramkasidan foydalanib sinab ko'ramiz.

Bizning ilovamiz nima qilishi kerak:

• Istalgan ikkita sonni qo‘shish, ayirish, bo‘lish va ko‘paytirish;
• Agar raqamdan boshqa narsa kiritilgan bo'lsa, ogohlantirishni ko'rsating va chiqing;
• Bundan tashqari, interfeys bo'lishi kerak buyruq qatori oxirgi foydalanuvchi dasturdan foydalanishi uchun.

Bizga nima kerak:

• Node.js va npm;
• JavaScript-ni bilish: kod sintaksisi va tuzilishi, ma'lumotlar turlari, matematik operatsiyalar va shartli ifodalar.

Maqsadlaringizni aniqlaganingizdan so'ng, siz sinov va rivojlanish uchun muhitni sozlashni boshlashingiz mumkin.

Biz Node.js dan foydalanayotganimiz sababli, fayllar va bog'liqliklar uchun mahalliy muhit yaratishimiz kerak.

Yaratmoq Yangi papka hisob. Buyruqlar satrida ushbu katalogga o'ting va npm init buyrug'i bilan yangi fayl yaratadigan yangi loyiha yarating. package.json dasturimiz uchun.

Sizdan paket nomi, versiyasi, tavsifi va paket haqidagi boshqa ma'lumotlarni kiritish so'raladi. Ism kiritishingiz mumkin calc.js bosishda davom eting Kirish standart qiymatlarni belgilash uchun. Sinov buyrug'iga kirganingizda, mocha ni kiriting - bu biz foydalanadigan sinov tizimi:

Barcha ma'lumotlarni kiritgandan so'ng, skript faylni yaratadi package.json, bu shunday ko'rinadi:

( "nom": "calc.js", "versiya": "1.0.0", "tavsif": "Node.js'dagi oddiy kalkulyator", "main": "index.js", "skriptlar": ( " test": "mocha" ), "muallif": "", "litsenziya": "ISC" )

Oxirgi qadam bu bosqichda- Mochani o'rnatish. O'rnatish uchun quyidagi buyruqni kiriting:

Npm install --save-dev mocha

Ushbu buyruqdan foydalangandan so'ng, papka paydo bo'ladi node_modules, fayl package-lock.json, va faylda package.json quyidagi qatorlar paydo bo'ladi:

"devDependencies": ("mocha": "^4.0.1")

Fayl yarating test.js. Biz Node.js ichiga o'rnatilgan moduldan foydalanamiz da'vo qilish rost va rost ekanligini tekshirish uchun. Bu to'g'ri bo'lgani uchun sinovdan o'tish kerak:

Const assert = require("assert"); it("to'g'ri qaytishi kerak", () => ( assert.equal(true, true); ));

Endi sinovni buyruq satridan ishga tushiring:

$ npm testi > mocha ✓ 1 marta (8ms) haqiqiy qaytishi kerak

Sinov kutilganidek o'tdi, shuning uchun biz muhitni sozlashni tugatdik. dan olib tashlang test.js qatordan tashqari hamma narsa const assert = require("assert"); .

Biz fayldan foydalanamiz test.js ilova yaratishning butun jarayoni davomida. Yana ikkita fayl yarating: operatsiyalar.js arifmetik va tekshirish funktsiyalari uchun va calc.js ilovaning o'zi uchun. Biz ularni juda uzun va murakkab bo'lib qolmasligi uchun juda ko'p fayllardan foydalanamiz. Mana bizning hozirgi fayllar ro'yxati:

• calc.js;
• node_modules;
• operatsiyalar.js;
• package-lock.json;
• package.json;
• test.js;

Ilovamiz uchun birinchi haqiqiy testni qo'shamiz.

Avvalo, ilovamiz istalgan ikkita sonni qo‘shish, ayirish, bo‘lish va ko‘paytirish imkoniyatiga ega bo‘lishi kerak. Bu shuni anglatadiki, ushbu operatsiyalarning har biri uchun biz alohida funktsiyani yaratishimiz kerak.

Qo'shish bilan boshlaylik. Biz ikkita raqamning kutilgan yig'indisi aniq olinadigan test yozamiz. Quyidagi kodda add() funktsiyasi 4 yordamida 1 va 3 yig'indisi teng yoki yo'qligini tekshiramiz:

Const assert = require("assert"); it("1 va 3 yig'indisini to'g'ri topadi", () => ( assert.equal(add(1, 3), 4); ));

Npm test buyrug'i yordamida testni o'tkazgandan so'ng, biz quyidagilarni ko'ramiz:

> mocha 0 o'tish (9ms) 1 muvaffaqiyatsiz 1) 1 va 3 yig'indisini to'g'ri topdi: ReferenceError: qo'shish bu aniqlanmagan Context.it saytida (test.js:5:16) npm ERR! Sinov muvaffaqiyatsiz tugadi. Batafsil ma'lumot uchun yuqoriga qarang.

ReferenceError: qo'shish aniqlanmagan xabari bilan sinov muvaffaqiyatsiz tugadi. Biz hali mavjud bo'lmagan add() funksiyasini sinab ko'rmoqdamiz, shuning uchun bu natija kutilmoqda.

Faylda add() funksiyasini yaratamiz operatsiyalar.js:

Const add = (x, y) => (+x) + (+y);

Bu funksiya ikkita x va y argumentlarini oladi va ularning summasini qaytaradi. X + y emas, balki (+ x) + (+ y) yozishimizni sezgan bo'lishingiz mumkin. Agar kirish satr bo'lsa, argumentni raqamga o'tkazish uchun unary operatordan foydalanamiz.

Eslatma Bu ES6-ga qo'shilgan o'q funktsiyasidan va yashirin qaytishdan foydalanadi.

Node.js dan foydalanayotganimiz va kodni bir nechta fayllarga bo‘lganimiz sababli kodni eksport qilish uchun module.exports dan foydalanishimiz kerak:

Const add = (x, y) => (+x) + (+y); module.exports = (qo'shish)

Fayl boshida test.js kodni import qilamiz operatsiyalar.js require() dan foydalaning. Funktsiyadan operatsiyalar o'zgaruvchisi orqali foydalanayotganimiz uchun add() ni operations.add() ga o'zgartirishimiz kerak:

Const operatsiyalari = talab ("./operations.js"); const assert = talab ("tasdiqlash"); it("1 va 3 yig'indisini to'g'ri topadi", () => ( assert.equal(operations.add(1, 3), 4); ));

Keling, testni bajaramiz:

$ npm test > mocha ✓ 1 va 3 1 o'tish (8ms) yig'indisini to'g'ri topadi

Endi bizda ish funksiyasi bor va testlar o‘tmoqda. Boshqa operatsiya funktsiyalari xuddi shunday ishlaganligi sababli, subtract() , multiply() va divide() uchun testlarni qo'shish oson:

It("1 va 3 yig'indisini to'g'ri topadi", () => ( assert.equal(operations.add(1, 3), 4); )); it("-1 va -1 yig'indisini to'g'ri topadi", () => ( assert.equal(operations.add(-1, -1), -2); )); it("33 va 3 o'rtasidagi farqni to'g'ri topadi", () => ( assert.equal(operations.subtract(33, 3), 30); )); it("12 va 12 ko'paytmasini to'g'ri topadi", () => ( assert.equal(operations.multiply(12, 12), 144); )); it("10 va 2 ning qismini to'g'ri topadi", () => ( assert.equal(operations.divide(10, 2), 5); ));

Endi barcha funksiyalarni yaratamiz va eksport qilamiz test.js:

Const add = (x, y) => (+x) + (+y); const ayirish = (x, y) => (+x) - (+y); const ko'paytirish = (x, y) => (+x) * (+y); const bo'linishi = (x, y) => (+ x) / (+ y); module.exports = (qo'shish, ayirish, ko'paytirish, bo'lish, )

Va keling, yangi testlarni o'tkazamiz:

$ npm test > mocha ✓ 1 va 3 yig'indisini to'g'ri topadi ✓ -1 va -1 yig'indisini to'g'ri topadi ✓ 33 va 3 ning ayirmasini to'g'ri topadi ✓ 12 va 12 ning ko'paytmasini to'g'ri topadi ✓ 10 ning qismini to'g'ri topadi va 2 5 o'tish (8ms)

Barcha testlar muvaffaqiyatli o'tdi, shuning uchun endi bizning ilovamizning asosiy funktsiyalari to'g'ri ishlashiga ishonch hosil qilishimiz mumkin. Endi siz qo'shimcha tekshirishni amalga oshirishingiz mumkin.

Hozircha, foydalanuvchi raqamni kiritib, kerakli operatsiyani tanlaganida, hamma narsa yaxshi ishlaydi. Biroq, agar siz raqam va satrning yig'indisini topishga harakat qilsangiz nima bo'ladi? Ilova operatsiyani bajarishga harakat qiladi, lekin u raqamni kutgani uchun NaNni qaytaradi.

Qandaydir g'alati qiymatni qaytarish o'rniga, ikkinchi vazifani bajarish vaqti keldi - agar kiritilgan argument raqam bo'lmasa, ilovani ogohlantirish va chiqishni ko'rsating.

Avval siz kiritilgan raqam yoki yo'qligini tekshiradigan funktsiyani yozishingiz kerak. Ilova faqat raqamlar bilan ishlashi kerak, shuning uchun biz uchta vaziyatni hal qilamiz:

validateNumbers() funksiyasi ikkala parametrni ham tekshiradi. isNaN() funksiyasi parametrning raqam ekanligini tekshiradi va agar bo'lmasa, false ni qaytaradi. Aks holda, u haqiqatni qaytaradi, bu muvaffaqiyatli tekshiruvdan dalolat beradi.

Const validateNumbers = (x, y) => ( if (isNaN(x) && isNaN(y)) ( false qaytaradi; ) rostni qaytaradi; )

Fayl oxirida module.exports ga validateNumbers qo'shishni unutmang. Endi siz yangi testlarni o'tkazishingiz mumkin:

$ npm test 1) raqam oʻrniga satrdan foydalanishda xatolik haqida xabar beradi ✓ raqam oʻrniga ikkita satrdan foydalanishda xatolik haqida xabar beradi ✓ ikkita raqamdan foydalanishda muvaffaqiyat 7 oʻtish (12ms) 1 muvaffaqiyatsiz 1) satrdan foydalanishda xatolik haqida xabar beradi raqam o'rniga: AssertionError: rost == noto'g'ri + kutilgan - haqiqiy - rost + yolg'on

Ikkita sinovdan o'tdi, ammo bittasi muvaffaqiyatsizlikka uchradi. Ikki raqam uchun test, ikkita satr uchun test muvaffaqiyatli o'tdi. Satr va raqam kiritilishini tekshirish haqida ham shunday deyish mumkin emas.

Funktsiyamizga yana qarasangiz, buni sezasiz ikkalasi ham funktsiya noto'g'ri qaytishi uchun parametrlar NaN bo'lishi kerak. Agar parametrlardan kamida bittasi NaN bo'lsa, biz bir xil effektga erishmoqchi bo'lsak, && ni || bilan almashtirishimiz kerak. :

Const validateNumbers = (x, y) => ( if (isNaN(x) || isNaN(y)) ( false qaytaradi; ) rostni qaytaradi; )

Agar ushbu o'zgarishlardan keyin siz yana npm testini ishga tushirsangiz, barcha testlar muvaffaqiyatli o'tadi:

✓ raqam o'rniga satrdan foydalanishda xatolik haqida xabar beradi ✓ raqam o'rniga ikkita satrdan foydalanishda xatolik haqida xabar beradi ✓ ikkita raqamdan foydalanishda muvaffaqiyat 8 o'tish (9ms)

Biz ilovamizning barcha funksiyalarini sinab ko'rdik. Funktsiyalar matematik operatsiyalarni muvaffaqiyatli bajaradi va kiritilgan ma'lumotlarni tasdiqlaydi. Yakuniy bosqich - foydalanuvchi interfeysini yaratish.

Bizda allaqachon kerakli funksiyalar mavjud, ammo foydalanuvchi hali ulardan foydalana olmaydi. Shuning uchun bizga interfeys kerak. Ilovamiz uchun buyruq qatori interfeysini yaratamiz.

Hozirda fayl calc.js bo'sh bo'lishi kerak. Bu bizning ilovamiz saqlanadigan joy. Avval funksiyalarni import qilishingiz kerak operatsiyalar.js:

Const operatsiyalari = talab ("./operations.js");

Interfeysning o'zi Node.js ichiga o'rnatilgan Readline CLI modulidan foydalanadi:

Const readline = require("readline");

Sizga kerak bo'lgan hamma narsani import qilgandan so'ng, ilovangizni yaratishni boshlashingiz mumkin. Interfeys yaratish uchun biz rl o'zgaruvchisi orqali kirish mumkin bo'lgan readline dan foydalanamiz:

Const rl = readline.createInterface((kirish: process.stdin, chiqish: process.stdout ));

Dasturni ishga tushirgandan so'ng foydalanuvchi ko'rishi kerak bo'lgan birinchi narsa - bu xush kelibsiz xabar va foydalanish bo'yicha ko'rsatmalar. Buning uchun biz console.log() dan foydalanamiz:

Console.log(` Calc.js Node.js da kalkulyator ochdingiz! Versiya: 1.0.0. Foydalanish: Foydalanuvchi ikkita raqam kiritishi va keyin ular bilan nima qilishni tanlashi kerak. `);

Kalkulyator funksiyalariga kirishdan oldin console.log() kutilganidek ishlayotganini tekshirib ko'raylik. Biz dasturni xabarni chop etishga va chiqishga majbur qilamiz. Buning uchun oxirida rl.close() usuliga qo'ng'iroq qo'shing.

Ilovani ishga tushirish uchun tugun va fayl nomini kiriting:

$ node calc.js Calc.js Node.js kalkulyatorini ochdingiz! Versiya: 1.0.0. Foydalanish: Foydalanuvchi ikkita raqamni kiritishi va keyin ular bilan nima qilishni tanlashi kerak.

Dastur xush kelibsiz xabarni ko'rsatadi va chiqadi. Endi biz foydalanuvchi ma'lumotlarini kiritishimiz kerak. Foydalanuvchidan quyidagilarni bajarish talab qilinadi: ikkita raqam va bitta operatsiyani tanlang. Har bir kirish rl.question() usuli bilan so'raladi:

Rl.question("Birinchi raqamni kiriting: ", (x) => ( rl.question("Ikkinchi raqamni kiriting: ", (y) => ( rl.question(` Quyidagi amallardan birini tanlang: Qo'shish ( +) Ayirish (-) Ko'paytirish (*) Bo'linish (/) Sizning tanlovingiz: `, (tanlov) => ( // rl.close(); )); )); ));

X o'zgaruvchisiga birinchi raqam, y ikkinchi raqam beriladi va tanlangan amalni tanlash. Endi bizning dasturimiz kiritishni so'raydi, lekin olingan ma'lumotlar bilan hech narsa qilmaydi.

Uchinchi kirishdan so'ng, faqat raqamlar kiritilganligini tekshirishingiz kerak. Buning uchun validateNumbers() funksiyasidan foydalanamiz. NOT operatoridan foydalanib, biz raqamlar kiritilganligini tekshiramiz va agar bo'lmasa, dasturni to'xtatamiz:

Agar (!operations.validateNumbers(x, y)) ( console.log("Faqat raqamlarni kiritish mumkin! Iltimos, dasturni qayta ishga tushiring."); )

Agar hamma narsa to'g'ri kiritilgan bo'lsa, endi siz avval yaratilgan operatsiyaga mos keladigan usulni ishga tushirishingiz kerak. To'rtta ishlov berish uchun mumkin bo'lgan variantlar tanlashda biz switch ifodasidan foydalanamiz va operatsiya natijasini ko'rsatamiz. Agar mavjud bo'lmagan operatsiya tanlangan bo'lsa, foydalanuvchiga qayta urinib ko'rishni aytadigan standart blok bajariladi:

Agar (!operations.validateNumbers(x, y)) ( console.log("Faqat raqamlarni kiritish mumkin! Iltimos, dasturni qayta ishga tushiring."); ) else ( almashtirish (tanlov) ( "1" holat: console.log(` $(x) va $(y) summasi $(operations.add(x, y)).`); break; "2" holati: console.log(`$(x) va $( orasidagi farq y) $(operations.subtract(x, y)).`); break; "3" hol: console.log(`$(x) va $(y) koʻpaytmasi $(operations.multiply) ga teng (x, y)).`) ; break; "4" holi: console.log(`$(x) va $(y) ning qismi $(operations.divide(x, y)).`); break; default: console.log("Iltimos, dasturni qayta ishga tushiring va 1 dan 4 gacha raqamni tanlang."); break; ) )

Eslatma Bu yerda console.log() funksiyalari ifodalarga ruxsat beruvchi shablon satrlaridan foydalanadi.

/** * Node.js-dagi oddiy kalkulyator, u * o'rnatilgan Readline buyruq qatori interfeysidan foydalanadigan kalkulyator ilovasidan foydalanadi. */ const operatsiyalari = talab ("./operations.js"); const readline = talab ("readline"); // Interfeys yaratish uchun readline dan foydalaning const rl = readline.createInterface(( kiritish: process.stdin, chiqish: process.stdout )); console.log(` Calc.js Node.js da kalkulyator ochdingiz! Versiya: 1.0.0. Foydalanish: Foydalanuvchi ikkita raqam kiritishi va keyin ular bilan nima qilishni tanlashi kerak. `); rl.question("Birinchi raqamni kiriting: ", (x) => ( rl.question("Ikkinchi raqamni kiriting: ", (y) => ( rl.question(` Quyidagi amallardan birini tanlang: Qo'shish ( +) Ayirish (-) Ko'paytirish (*) Bo'linish (/) Sizning tanlovingiz: `, (tanlov) => ( agar (!operations.validateNumbers(x, y)) ( console.log("Faqat raqamlarni kiritish mumkin! Iltimos, dasturni qayta ishga tushiring. "); ) else ( switch (tanlov) ( "1" holat: console.log(`$(x) va $(y) yig'indisi $(operations.add(x, y)). `); break; "2" holati: console.log(`$(x) va $(y) o'rtasidagi farq $(operations.subtract(x, y)).`); break; "3" hol: console.log(`$( x) va $(y) ko`paytmasi $(operations.multiply(x, y) ga teng).`); break; case "4": console.log(`Katlanish qismi $(x) va $(y) $(operatsiyalar. divide(x, y)).`); break; default: console.log("Iltimos, dasturni qayta ishga tushiring va 1 dan 4 gacha raqamni tanlang." ); break; ) ) rl.close(); )); ))) ; ));

Endi bizning arizamiz tayyor. Keling, uning ishini oxirgi marta tekshirib ko'ramiz. 999 va 1 ni kiriting va ayirish amalini tanlang:

$ node calc.js Birinchi raqamni kiriting: 999 Ikkinchi raqamni kiriting: 1 Sizning tanlovingiz: 2 999 va 1 orasidagi farq 998 ga teng.

Dastur o'z ishini muvaffaqiyatli yakunlab, to'g'ri natija berdi. Tabriklaymiz, siz Node.js yordamida oddiy kalkulyator yozdingiz va TDDni ishlab chiqish asoslarini o‘rgandingiz.

Kod testi ajralmas rivojlanish tsiklidir dasturiy ta'minot. Boshlang'ich ishlab chiqish guruhlari ko'pincha uning rolini kam baholaydilar va dasturning funksionalligini eski usulda tekshiradilar - "bu ishlaydi, mayli". Ertami-kechmi, bu strategiya barbod bo'ladi va xato kuzatuvchisi son-sanoqsiz vazifalar armiyasi bilan to'lib-toshgan bo'la boshlaydi. Bunday tuzoqqa tushib qolmaslik uchun men JavaScript kodini sinab ko'rishning nuanslarini tushunishni bir marta tavsiya qilaman.

Bugungi kunda JavaScript shunchaki narsalarni ziravor qilish uchun til emas ko'rinish ilovalar. JavaScript-dan hazil qilish yoki menyu yaratish uchun foydalanilgan vaqtlar qaytarib bo'lmaydigan darajada o'tib ketdi. Endi bu mijoz va serverda bir xil darajada yaxshi ishlaydigan mustaqil til. JavaScript-ning roli sezilarli darajada oshdi, ya'ni kod yozishda boshqa dasturlash tillarida o'zini isbotlagan amaliyotlardan foydalanishdan uyalmaslik kerak.

Amaliyotlar va paradigmalar deganda nimani tushunaman? Albatta, MVC (modelni ko'rish boshqaruvchisi) me'moriy naqsh va kodni tashkil etish naqshlari. Ushbu oddiy fokuslarga rioya qilish orqali siz nafaqat parvarish qilish oson bo'ladigan, balki avtomatik ravishda sinovdan o'tish qobiliyatiga ega bo'lgan yaxshiroq kod yozishingiz mumkin bo'ladi.

Hech kimga sir emaski, sinovning eng mashhur usuli har doim oddiy ko'z testi bo'lgan. Uning mohiyati sharmandali darajada sodda - siz bir necha ming qator kodlarni yozasiz, muammoni hal qilasiz va ijodingizni ishga tushirasiz. Men o'ynadim, bosdim, hamma narsa ishlayotganga o'xshaydi, uni ishlab chiqarish serveriga yuklashingiz mumkin. Hammasi juda oddiy va ishlab chiquvchining diqqat-e'tibori bilan (ideal "sinovchi" laqabli shaxs), siz dasturning to'g'ri ishlashiga ishonishingiz mumkin.

Amalda, hamma narsa biroz boshqacha sodir bo'ladi. Qoida tariqasida, alohida tester yo'q. Ishlab chiquvchining o'zi texnik spetsifikatsiyalarda ko'rsatilgan harakatlar ketma-ketligini bajarish orqali dasturning funksionalligini tekshirishga harakat qiladi. Keyinchalik ilg'or kod soxtalashtirish Selenium kabi narsalardan foydalangan holda bunday integratsiya testlarini avtomatlashtiradi.

Shunday qilib, dasturchi faqat eng jiddiy xatolarni aniqlash imkoniyatiga ega bo'ladi. Afsuski, foydalanuvchilarning “ahmoqona” va “ko‘zda tutilmagan” harakatlari, shuningdek, biznes mantig‘idagi ayyor harakatlar 99% hollarda parda ortida qoladi.

Sinovchi shaxsida alohida shaxsning mavjudligi ham muammoni qisman va ma'lum bir vaqtgacha hal qiladi. Sapperning tafsilotlarga e'tiborini e'tiborsiz qoldiradigan bo'lsak ham, dastur o'sishi bilan uning sinov sifati nolga tushadi. Sizga amaliyotdan misol keltiraman.

Bir kuni menga kichik dastur ishlab chiqish topshirildi. Funktsionallik nuqtai nazaridan, loyiha men eng qisqa vaqt ichida amalga oshirgan oddiy CRM-ga o'xshardi. Tegishli mukofotni olgach, men barcha manbalarni mijozga topshirdim va sakkiz oy davomida loyihani unutdim. Keyin kulgi boshlandi. Xaridor dasturning funksionalligini jiddiy ravishda kengaytirishga qaror qildi va meni yordamga chaqirdi. Tabiiyki, men uni oldim va funktsiyadan keyin yangi funktsiyani haykal qila boshladim. Avvaliga bu qiyin emas edi, lekin funksionallikning umumiy integratsiyasi haqida gap ketganda, mening yo'nalishimga hasharotlar to'dasi yugurdi. Kod qismlari qarama-qarshilik qila boshladi va biz mojarolarni hal qilish uchun ko'p vaqt sarflashimiz kerak edi. "Xo'sh, qanday qilib arizangiz bilan bog'liq muammolar borligini ko'rmadingiz?" - deb so'raydi diqqatli o'quvchilar. Men uni ishga tushirdim, lekin dastur o'sib ulg'ayganligi sababli, barcha funktsiyalarni ommaviy ravishda sinab ko'rish uchun vaqtim va asabim etarli emas edi. Men o'zimni faqat individual funktsiyalarni sinab ko'rish bilan chekladim va buning uchun yaxshi pul to'ladim. Hikoyaning axloqi "Sinovni rivojlanishning ajralmas qismi sifatida o'ylab ko'ring".

Birlik testi asablarni tejash va dasturning alohida qismlarining funksionalligi kafolatlarini oshirishning eng yaxshi usuli hisoblanadi. Agar siz bu dahshatli so'zni hech qachon uchratmagan bo'lsangiz, unda men qisqacha tushuntiraman. Birlik testlari sinov jarayonini avtomatlashtirish va ilovangizning har bir xususiyatini sinab ko'rish imkonini beradi.

Rivojlanish tugagandan so'ng yangi xususiyat(ishlab chiqish boshlanishidan oldin testlarni yozish mumkin) ishlab chiquvchi o'z kodini sinab ko'rish uchun maxsus kod yozadi. Sinov kodingizda siz turli vaziyatlarni simulyatsiya qilishingiz va qiymatlarni qaytarishingiz kerak. Misol uchun, biz bo'shliqlarni kesish (qirqish) funktsiyasini yozdik. Uning ishlashini sinab ko'rish uchun biz quyidagilarni aytishimiz mumkin bo'lgan bir nechta testlarni tayyorlashimiz kerak:

Shuningdek, biz boshqa kiritish parametrlari uchun test qo'shishimiz mumkin (masalan, bo'sh joy belgisini yorliq bilan almashtirish). Umuman olganda, biz kodni testlar bilan qanchalik yaxshi qamrab olsak va mumkin bo'lgan salbiy variantlarni ta'minlasak, eng muhim daqiqada boshida ozgina soch qolishi ehtimoli shunchalik yuqori bo'ladi.

JS dunyosida testlar odatda maxsus ramkalar yordamida yoziladi. Ularda testlarni tavsiflash uchun kerak bo'lgan hamma narsa, shuningdek, test natijalari bo'yicha hisobotlarni tizimlashtirish uchun hech bo'lmaganda ba'zi vositalar mavjud.

Birlik testidan foydalanmaydigan ishlab chiquvchilar birlik testi qo'shimcha kod yozish va saqlashni talab qiladi, deb bahslashishni yaxshi ko'radilar. Ularning ta'kidlashicha, haqiqiy loyihalarda muddatlar ko'pincha qattiq va qo'shimcha kod yozishning iloji yo'q.

Men qat'iy muddatlarga roziman, lekin qo'shimcha kod haqida bahslashishga tayyorman. Bir tomondan, ha, testlar qo'shimcha kodni talab qiladi va shuning uchun uni yozish uchun vaqt kerak. Boshqa tomondan, ushbu kod avtomobilda havo yostig'i vazifasini bajaradi va dastur o'sib borishi bilan, albatta, o'zini to'laydi.

Vaqtingiz yo'q bo'lsa va yozish testlaridan voz kechish istagi bilan qiynalganingizda, uch marta o'ylab ko'ring. Bunday holda, testdan butunlay voz kechgandan ko'ra, kodning faqat eng qiyin bo'limlarini testlar bilan qamrab olish maqsadga muvofiqdir. Har doim kelajakni ko'z bilan o'ylab ko'ring, go'yo bir oy ichida sizning dasturingiz misli ko'rilmagan darajada o'sishi mumkin.

Nima uchun asosiy kodni yozishdan oldin test haqida o'ylash kerak, deb aytaman? Ha, chunki dastlab birlik testlari bilan qamrab olinishi kerak bo'lgan kod biroz boshqacha uslubda yozilgan. Har bir kodni sinab ko'rish mumkin emas. Mantiq va tasavvurlarni aralashtirib yuboradigan kod, shuningdek, to'g'ri sinovdan o'tkazish mumkin bo'lmagan joylarga tiqilib qoladi. Bu erda men har doim bir nechta oddiy qoidalarga amal qilishni maslahat beraman:

QUnit ayniqsa JavaScript ishlab chiquvchilari orasida mashhur. Birinchidan, u yaxshi hujjatlashtirilgan va ulardan foydalanish oson, ikkinchidan, u jQuery mualliflari tomonidan yaratilgan. Kutubxona jQuery-ga asoslangan va mahalliy JavaScript kodini sinab ko'rish uchun javob beradi.

Yuklab olish oxirgi versiya Siz QUnit-dan rasmiy veb-saytdan foydalanishingiz mumkin - http://qunitjs.com/. Kutubxona bitta JS va sifatida keladi CSS fayli. Aytaylik, siz kerakli komponentlarni yuklashni aniqladingiz va agar shunday bo'lsa, sinov sinovini yozish vaqti keldi. Uzoqqa bormaylik va yuqorida tilga olingan trim() funksiyasini sinab ko‘rishga harakat qilaylik.

Sinovlarni namoyish qilish uchun men quyidagi konstruktor bilan oddiy loyiha yaratdim:

Index.html – test natijalarini aks ettiruvchi asosiy fayl; - qunit-1.12.0.js – qunit kutubxona fayli; - example.js – sinov uchun kodni o'z ichiga olgan fayl (bizning holimizda trim() funksiyasining tavsifi); - test.js – testlar bilan fayl; - qunit-1.12.0.css – testlar bilan hisobotni loyihalash uslublari;

index.html va test.js fayllari mazmuni 1 va 2 roʻyxatlarda keltirilgan. Bizni koʻproq ikkinchi roʻyxat qiziqtiradi, unda sinovdan oʻtayotgan funksiya deklaratsiyasi (trim()) va uni tekshirish uchun test kodi mavjud. funksionallik. Iltimos, trim() funksiyasining o'zi istalgan joyda joylashgan bo'lishi mumkinligini unutmang; Men uni jurnalda joy tejash uchun ikkinchi ro'yxatga kiritdim.

Endi testlarning o'zlarini ko'rib chiqaylik. Kodimizning funksionalligini tekshirish uchun Qunit.js kutubxonasi bizga bir qancha usullarni taklif qiladi:

Ikkinchi ro'yxatda men ushbu usullarni amalda qo'llashni aniq ko'rsatdim. Agar siz ushbu shaklda test namunasini ishga tushirsangiz, barcha testlar muvaffaqiyatli o'tadi (tegishli rasmga qarang). O'tgan va muvaffaqiyatsiz bo'lgan testlar o'rtasidagi farqni ko'rish uchun men bitta test uchun kodni biroz o'zgartirdim. Men ataylab strictEqual() dan foydalanib test chizig'iga noto'g'ri natija qo'shdim (tegishli rasmga qarang).

Biz oddiy funktsiyalarni sinab ko'rishni saralab oldik. Qanday bo'lmasin, menda qo'shimcha hech narsa yo'q. Keyinchalik, siz haqiqiy kodni olishingiz va testlarni o'zingiz yozishga harakat qilishingiz kerak. Keling, JavaScript ishlab chiquvchilari uchun tez-tez uchraydigan yana bir vazifani ko'rib chiqaylik - asinxron funktsiyalarni sinab ko'rish. JavaScript kodi bilan to'ldirilgan dastur Ajax yordamida server tomoni bilan 99% o'zaro ta'sir qiladi. Siz bu kodni ham belgisiz qoldira olmaysiz, lekin testlarni yozish biroz boshqacha ko'rinadi. Keling, bir misolni ko'rib chiqaylik:

AsyncTest("myAsyncFunc()", function() ( setTimeout(function() ( ok(myAsyncFunc() == rost, "Ma'lumotlar muvaffaqiyatli uzatildi"); start(); ), 500); ));

Bu misol va oldingi misol o'rtasidagi asosiy farq shundaki, test() o'rami o'rniga asyncTest() ishlatiladi va shu bilan men maxsus asinxron testni sinab ko'rishga qiziqayotganimni bevosita bildiradi. Keyin kutish vaqtini 500 ml dan boshlayman. sek. Bu vaqt ichida myAsyncFunc() funksiyasi test serveriga ma'lumotlarni uzatishi kerak va agar hammasi yaxshi bo'lsa, true qiymatini qaytaradi. Bu erda eng qiziqarli daqiqalar keladi. asyncTest() chaqirilganda, bajarilish oqimi to'xtaydi va test tugagach, uni mustaqil ravishda ishga tushirish kerak. Bajarish oqimini boshqarish uchun QUnit start() va stop() usullariga ega.

QUnit kutubxonasi yordamida asinxron funktsiyalarni sinab ko'rish juda oddiy. Men ko'rib chiqmoqchi bo'lgan oxirgi misol bir nechta asenkron tekshiruvlarni amalga oshiradigan test yozishni o'z ichiga oladi. Bunday vazifalarda paydo bo'ladigan asosiy savol - ijro oqimini boshlash uchun optimal joy. Rasmiy doc quyidagi kabi narsalarni ishlatishni taklif qiladi:

AsyncTest("myAsyncFunc()", function() ( wait(3); //Bu yerda biz uchta tekshiruvni bajaramiz ok(myAsyncFunc(), "Dunyoni yaxshiroq joyga aylantiramiz 1"); ok(myAsyncFunc()," dunyo yaxshiroq joy 2") ; ok(myAsyncFunc(), "Dunyoni yaxshiroq joyga aylantirish 3"); setTimeout(function() (start(); ), 3000); ));

Har doim esda tutishingiz kerakki, ko'plab interfeyslar JavaScript-da yozilgan. Misol uchun, foydalanuvchi pimpni bosadi va uning sekin urishiga javoban biror narsa sodir bo'lishi kerak. Loyihalarda bunday "interfeys" kodining juda ko'p miqdori mavjud va u ham testlar bilan qamrab olinishi kerak. Keling, qanday qilib foydalanuvchi tugmachasini bosishni taqlid qilishimiz va bu harakat uchun alohida test yozishimiz mumkinligini ko'rib chiqamiz. Tasavvur qilaylik, bizda bosilgan tugmalarni qayd qiluvchi ma'lum bir funktsiya mavjud. Men uning kodini uchinchi ro'yxatda taqdim etdim:

Endi ushbu funktsiyani sinab ko'rishga harakat qilaylik. Avvalo, testning tanasida biz bosilgan tugmachani taqlid qilishimiz kerak. Buni amalga oshirishning eng oson yo'li jQuery kutubxonasi bo'lib, u sizga bir necha qator kodlarda voqea yaratish imkonini beradi (Ro'yxat 4-ga qarang).

Sinov ro'yxatining boshida men "tugmachani pastga" tugmachasini bosishni taqlid qilish uchun voqea tayyorlayman. Tab tugmachasini bosish bizni qiziqtiradi (kod 9). Keyin, trigger() usulidan foydalanib, men tayyorlangan hodisani yuboraman, shundan so'ng men sinovni boshlashim mumkin. Birinchidan, biz umumiy rasmni tekshiramiz - tugma bosilganmi, keyin esa uning kodi.

Qunit.js foydalanuvchi harakatlarini sinab ko'rish imkonini berganligi sababli, DOM uchun testlarni yozish ham muammo tug'dirmasligi kerak. Bu haqiqatan ham to'g'ri va quyidagi misol mening so'zlarimni tasdiqlaydi. Men bunga izoh bermayman, shunchaki kodga qarang va hamma narsa aniq bo'ladi:

Test("Yangi div elementini qo'shish", function() ( var $fixture = $("#qunit-fixture"); $fixture.append("Bu yangi div"); teng($("div", $fikstür) .length, 1, "Yangi div muvaffaqiyatli qo'shildi!"); ));

Qunit.js kutubxonasidan foydalangan holda testlarni yozish qulay va sodda, ammo ertami-kechmi testni boshlash va natijalarni yig'ishni qandaydir tarzda avtomatlashtirish istagi sizni hayratda qoldiradi. Masalan, menda bu masala uchun alohida narsa bor virtual mashina DigitalOcean-da, men uni faqat konsol yordamida boshqarishim mumkin.

Phantom.js loyihasi bu muammoni juda oqlangan tarzda hal qiladi. Bu Unit testlarini yozish uchun boshqa ramka emas, balki WebKit dvigatelining to'liq huquqli konsol versiyasi. Oddiy qilib aytganda, ushbu ilova brauzerga taqlid qiladi. Phantom.js yordamida nafaqat test bajarilishini tekshirishni avtomatlashtirish, balki ertami-kechmi dasturchi oldida paydo bo'ladigan ko'plab muammolarni hal qilish mumkin: sahifani ko'rsatish natijalarini faylga (png, jpg), tarmoqqa olish. monitor funksiyalari (yuklash tezligi, umumiy unumdorlik va h.k.), foydalanuvchi harakatlarini emulyatsiya qilish va h.k. Men sizga vaqt ajratib, ushbu loyiha bo'yicha rasmiy hujjatlarni o'qib chiqishingizni maslahat beraman, albatta o'zingiz uchun qiziqarli narsalarni topasiz.

Phantom.js turli platformalar uchun kompilyatsiya qilinishi mumkin (nix, mac OS X, windows). Agar siz hamma narsani Windows-da ishlab chiqsangiz, unda hech qanday muammo bo'lmaydi - ikkilik fayllarni birlashtiring va davom eting. Agar sizda ikkita video adapter o'rnatilgan bo'lsa, ulardan biri NVidia bo'lsa, ishga tushirish bilan bog'liq kichik muammolar paydo bo'lishi mumkin. Bunday holda, siz yon panelda tasvirlangan hackdan foydalanishingiz kerak bo'ladi.

Keling, phantom.js bilan amalda tanishishga harakat qilaylik. Oxirgi bo'limda tayyorlangan testlarni phantom.js orqali bajarish va ijro natijalarini konsolga olish uchun bizga maxsus yuklovchi skripti kerak - run-qunit.js. Konsolni oching (men Windowsda ishlayman, shuning uchun cmd dan foydalanaman) va buyruqni formatda yozing:

Phantom.exe

Mening holimda ishga tushirish buyrug'i quyidagicha ko'rinardi:

E:\soft\phantomjs>phantomjs.exe E:\temp\testjsforx\qunit\run-qunit.js file:///E: /temp/testjsforx/qunit/index.html Uni bajarish natijasi: Testlar yakunlandi 2592 millisekund. 9 ta tasdiqdan 9 tasi o'tdi, 0 tasi muvaffaqiyatsiz.

Siz yaratayotgan dastur qanday miqyosda bo'lishidan qat'i nazar, kodingizni testlar bilan qoplashingiz kerak. Yana bir bor eslatib o'tamanki, hatto eng kichik dasturlar ham qo'llab-quvvatlanishi va qo'shilishi kerak bo'lgan qo'pol hayvonlarga aylanadi. Yaxshi sinovdan o'tgan kod muvaffaqiyat va sifat kalitidir. Ha, avtomatlashtirilgan testlar uchun mos kod yozishni darhol boshlash oson emas, lekin menga ishoning, bu azoblarning barchasi kelajakda o'zini oqlaydi. Bugun hammasi shu, omad tilaymiz!

Agar vaqtingiz bo'lmasa, oddiy funktsiyalar uchun testlarni yozishdan ma'no yo'q (maqoladagi misollardan bir xil trim() ni oling); kodning eng muhim bo'limlariga e'tibor qaratgan ma'qul. Tez-tez o'zgartiriladigan kodni yozishda ham xuddi shunday qoidaga amal qilish kerak. Jonli loyihaning texnik xususiyatlari tez-tez o'zgarib turadi va ba'zi funktsiyalar doimiy ravishda yangilanib turishi kerak. Bunday o'zgarishlar yoqimsiz daqiqalarga olib kelishi mumkin - o'zgartirilgan kod yangi ma'lumotlar bilan yaxshi ishlaydi, lekin eski ma'lumotlarni organik ravishda hazm qilmaydi. Shunday qilib, bu erda muvaffaqiyatsizlikka uchramaslik uchun darhol bunday funktsiyalarni testlar bilan qoplash yaxshiroqdir. Oddiy qoidani eslang - butun kodni testlar bilan qoplash uchun vaqt yo'q, uning eng muhim qismini qamrab oladi.

Bu shunday bo'ldi, lekin men ushbu maqoladagi barcha misollarni Linuxda emas, balki eski yaxshi Windows 7 da sinab ko'rdim. Ma'lum bo'lishicha, phantom.js bir nechta video adapterlardan foydalanadigan tizimlarda ishlashda kichik muammolarga duch keladi. Mening noutbukimda, o'rnatilgan video chipidan tashqari, NVidia ham mavjud va phantom.js tufayli u phantom.exit() buyrug'iga javob berishni qat'iyan rad etdi. Natijada, skript bajarilgandan so'ng, phantom.js jarayoni o'z ishini yakunlamadi va xotirada osib qo'yishda davom etdi. Terminal oynasi ham o'chirish buyruqlariga javob berishni to'xtatdi (ctrl + c yordam bermadi).

Agar siz ham shunga o'xshash muammoga duch kelsangiz va Windows-da phantom.js-dan foydalanishni rejalashtirmoqchi bo'lsangiz, unda quyidagi buzishni amalga oshirishga tayyor bo'ling. Nvidia boshqaruv panelini oching. Daraxtdagi "3D sozlamalari" bandini toping. O'ng tomonda "Afzallashtirilgan grafik adapter" opsiyasi paydo bo'lishi kerak. Odatiy bo'lib, uning qiymati "Avtomatik tanlash" ga o'rnatiladi. Uni "Yuqori unumdor Nvidia protsessor" yoki "Integratsiyalashgan grafik apparat" ga o'zgartirishimiz kerak. Ushbu oddiy hiyladan so'ng, phantom.js o'zini itoatkorlik bilan tuta boshladi.

Sinov dasturiy ta'minotni ishlab chiqish tsiklining ajralmas qismidir. Boshlang'ich ishlab chiqish guruhlari ko'pincha uning rolini kam baholaydilar va dasturning funksionalligini eski usulda tekshiradilar - "bu ishlaydi, mayli". Ertami-kechmi, bu strategiya barbod bo'ladi va xato kuzatuvchisi son-sanoqsiz vazifalar armiyasi bilan to'lib-toshgan bo'la boshlaydi. Bunday tuzoqqa tushib qolmaslik uchun men JavaScript kodini sinab ko'rishning nuanslarini tushunishni bir marta tavsiya qilaman.

Men sizga bugungi kunda JavaScript shunchaki ilova ko'rinishini ziravor qiladigan til emasligini tushuntirishim shart emas. Lekin baribir tushuntiraman va bir oz muqaddima qilaman, chunki keyin menga yanada ko'proq pul to'lanadi! 🙂 Shunday qilib, JavaScript-dan hazil qilish yoki menyu yaratish uchun foydalanilgan vaqtlar qaytarib bo'lmaydigan darajada o'tib ketdi. Endi bu mijoz va serverda bir xil darajada yaxshi ishlaydigan mustaqil til. JavaScript-ning roli sezilarli darajada oshdi, ya'ni kod yozishda boshqa dasturlash tillarida o'zini isbotlagan amaliyotlardan foydalanishdan uyalmaslik kerak.

Amaliyotlar va paradigmalar deganda nimani tushunaman? Albatta, MVC (modelni ko'rish boshqaruvchisi) me'moriy naqsh va kodni tashkil etish naqshlari. Ushbu oddiy fokuslarga rioya qilish orqali siz nafaqat parvarish qilish oson bo'ladigan, balki avtomatik ravishda sinovdan o'tish qobiliyatiga ega bo'lgan yaxshiroq kod yozishingiz mumkin bo'ladi.

• Sinov imkon qadar sodda bo'lishi kerak. Sinov qanchalik murakkab bo'lsa, xato qilish ehtimoli shunchalik yuqori bo'ladi.
• Keyinchalik xatolarni topishni osonlashtirish va dasturning muayyan qismlarini sinab ko'rish uchun testlarni modullarga guruhlash kerak.
• Har bir test boshqa testlardan mustaqil bo'lishi kerak.
• Xatolar topilganda har doim alohida test yozing.

Hech kimga sir emaski, sinovning eng mashhur usuli har doim oddiy ko'z testi bo'lgan. Uning mohiyati sharmandali darajada sodda - siz bir necha ming qator kodlarni yozasiz, muammoni hal qilasiz va ijodingizni ishga tushirasiz. Men o'ynadim, bosdim - hamma narsa ishlayotganga o'xshaydi, uni ishlab chiqarish serveriga yuklashingiz mumkin. Hammasi juda oddiy va ishlab chiquvchining diqqat-e'tibori bilan (ideal "sinovchi" laqabli shaxs) siz dasturning to'g'ri ishlashiga ishonishingiz mumkin.

Amalda, hamma narsa biroz boshqacha sodir bo'ladi. Qoida tariqasida, alohida tester yo'q. Ishlab chiquvchining o'zi texnik spetsifikatsiyalarda ko'rsatilgan harakatlar ketma-ketligini bajarish orqali dasturning funksionalligini tekshirishga harakat qiladi. Keyinchalik ilg'or kod soxtalashtirish Selenium kabi vositalardan foydalangan holda ushbu turdagi integratsiya testlarini avtomatlashtiradi.

Shunday qilib, dasturchi faqat eng jiddiy xatolarni aniqlash imkoniyatiga ega bo'ladi. Afsuski, foydalanuvchilarning “ahmoqona” va “ko‘zda tutilmagan” harakatlari, shuningdek, biznes mantig‘idagi ayyor harakatlar 99% hollarda parda ortida qoladi.

Alohida testerning mavjudligi ham muammoni qisman va ma'lum vaqtgacha hal qiladi. Sapperning tafsilotlarga e'tiborini e'tiborsiz qoldiradigan bo'lsak ham, dastur o'sishi bilan uning sinov sifati nolga tushadi. Sizga amaliyotdan misol keltiraman.

Bir kuni menga kichik dastur ishlab chiqish topshirildi. Funktsionallik nuqtai nazaridan, loyiha men eng qisqa vaqt ichida amalga oshirgan oddiy CRM-ga o'xshardi. Tegishli mukofotni olgach, men barcha manbalarni mijozga topshirdim va sakkiz oy davomida loyihani unutdim. Keyin kulgi boshlandi. Xaridor dasturning funksionalligini jiddiy ravishda kengaytirishga qaror qildi va meni yordamga chaqirdi. Tabiiyki, men uni qabul qildim va funktsiyadan keyin funktsiyani haykaltaroshlik qila boshladim ... Avvaliga bu qiyin emas edi, lekin funksionallikning umumiy integratsiyasi haqida gap ketganda, mening yo'nalishimga hasharotlar to'dasi yugurdi. Kod qismlari qarama-qarshilik qila boshladi va biz mojarolarni hal qilish uchun ko'p vaqt sarflashimiz kerak edi. "Xo'sh, qanday qilib arizangiz bilan bog'liq muammolar borligini ko'rmadingiz?" – deb so‘raydi o‘quvchilar. Men javob beraman: men uni ishga tushirdim, lekin dastur o'sib ulg'ayganligi sababli, barcha funktsiyalarni ommaviy ravishda sinab ko'rish uchun vaqtim va asabim yo'q edi. Men o'zimni faqat individual funktsiyalarni sinab ko'rish bilan chekladim va buning uchun yaxshi pul to'ladim. Hikoyaning axloqi: "Sinovni rivojlanishning ajralmas qismi sifatida o'ylab ko'ring."

Birlik testi asablarni tejash va dasturning alohida qismlarining funksionalligi kafolatlarini oshirishning eng yaxshi usuli hisoblanadi. Agar siz bu dahshatli hayvonni hech qachon uchratmagan bo'lsangiz, unda men qisqacha tushuntiraman. Birlik testlari sinov jarayonini avtomatlashtirish va ilovangizning har bir xususiyatini sinab ko'rish imkonini beradi.

Yangi funktsiyani ishlab chiqishni tugatgandan so'ng (ishlab chiqish boshlanishidan oldin testlarni yozish mumkin), ishlab chiquvchi o'z kodini sinab ko'rish uchun maxsus kod yozadi. Turli vaziyatlarni simulyatsiya qilish va qiymatlarni qaytarish kerak. Misol uchun, biz bo'shliqlarni kesish (qirqish) funktsiyasini yozdik. Uning ishlashini sinab ko'rish uchun biz quyidagilarni aytishimiz mumkin bo'lgan bir nechta testlarni tayyorlashimiz kerak:

• "string" satrini o'tkazishda biz chiqish sifatida "string" olamiz;
• "9-qator" atamalarini uzatishda biz chiqishda "9-qator" ni olamiz;

Shuningdek, biz boshqa kiritish parametrlari uchun test qo'shishimiz mumkin (masalan, bo'sh joy belgisini yorliq bilan almashtirish). Umuman olganda, biz kodni testlar bilan qanchalik yaxshi qamrab olsak va mumkin bo'lgan salbiy variantlarni qanchalik ko'p ta'minlasak, eng muhim daqiqada boshida ozgina soch qolishi ehtimoli shunchalik yuqori bo'ladi.

JS dunyosida testlar odatda maxsus ramkalar yordamida tasvirlanadi. Ularda buning uchun kerak bo'lgan hamma narsa, shuningdek, test jarayoni haqida hisobotlarni tizimlashtirish uchun ba'zi vositalar mavjud.

Birlik testidan foydalanmaydigan ishlab chiquvchilar birlik testi qo'shimcha kod yozish va saqlashni talab qiladi, deb bahslashishni yaxshi ko'radilar. Ularning ta'kidlashicha, haqiqiy loyihalarda muddatlar ko'pincha qattiq va qo'shimcha kod yozishning iloji yo'q.

Agar vaqtingiz bo'lmasa, oddiy funktsiyalar uchun testlarni yozishdan ma'no yo'q (maqoladagi misoldan bir xil trim() ni oling); kodning eng muhim bo'limlariga e'tibor qaratish yaxshiroqdir. Tez-tez o'zgartiriladigan kodni yozishda ham xuddi shunday qoidaga amal qilish kerak. Jonli loyihaning texnik xususiyatlari tez-tez o'zgarib turadi va ba'zi funktsiyalar doimiy ravishda yangilanishi kerak. Bunday o'zgarishlar yoqimsiz daqiqalarga olib kelishi mumkin - o'zgartirilgan kod yangi ma'lumotlar bilan yaxshi ishlaydi, lekin eski ma'lumotlarni organik ravishda hazm qilmaydi. Bu erda xatolikka yo'l qo'ymaslik uchun darhol bunday funktsiyalarni tekshirish yaxshiroqdir. Oddiy qoidani eslang: butun kodni testlar bilan qoplash uchun vaqt yo'q - uning eng muhim qismini qamrab oling.

• Cristian Johansenning Test-Driven JavaScript Development (goo.gl/mE6Is) JavaScript-ga test yozish nuqtai nazaridan qaraydigan kam sonli kitoblardan biridir.
• Jon Resing, Beer Bibo "JavaScript Ninja sirlari" (goo.gl/xquDkJ) yaxshi kitob bo'lib, u birinchi navbatda o'rtacha tayyorgarlik darajasiga ega JS dasturchilari uchun foydali bo'ladi. Kitobda samarali kross-brauzer kodini yozish masalalari, voqealarni qayta ishlashning nuanslari va boshqa ko'plab yaxshi narsalar batafsil muhokama qilinadi.
• David Flanagan JavaScript. To'liq qo'llanma"(goo.gl/rZjjk) - kitob olti marta qayta nashr etilgan va har bir nashr bestsellerga aylanadi. Darhaqiqat, bu eng ko'p batafsil qo'llanma JavaScript-da, har bir JS dasturchisi kamida bir marta o'qishi kerak.
• PhantomJS + JSCoverage + QUnit yoki qamrovni hisoblash bilan konsol JS birligi testlari (goo.gl/FyQ38) - maqola muallifi to'plamdan foydalanishni namoyish etadi ro'yxatga olingan paketlar statistik ma'lumotlarni to'plash va testlar bilan kodni qoplash foizini hisoblash.
• PhantomJS-dan foydalanishning foydali misollari - sahifada PhantomJS-ning ko'plab jangovar ilovalari taqdim etilgan.

Nima uchun asosiy kodni yozishdan oldin test haqida o'ylash kerak, deb aytaman? Ha, chunki dastlab birlik testlari bilan qamrab olinishi kerak bo'lgan kod biroz boshqacha uslubda yozilgan. Har bir kodni sinab ko'rish mumkin emas. Mantiq va tasavvurlar aralashgan va hatto kim qaerdaligini biladigan kodni to'g'ri tekshirish mumkin emas. Bu erda men har doim bir nechta oddiy qoidalarga rioya qilishni maslahat beraman:

• Katta funktsiyalarni yozish kerak emas. Har bir funktsiya 100 500 ta mumkin bo'lgan vaziyatni emas, balki bitta muammoni hal qilishi kerak. Masalan, serverga ma'lumotlarni yuborish uchun kodni uni tayyorlash uchun mas'ul bo'lgan funktsiyaga qo'yishning hojati yo'q.
• O'ndan ortiq kod qatoridan iborat funktsiya, ehtimol, yomon funktsiyadir.
• Mantiq va taqdimot hech qachon birga bo'lmasligi kerak.

QUnit ayniqsa JavaScript ishlab chiquvchilari orasida mashhur. Birinchidan, u yaxshi hujjatlashtirilgan va ulardan foydalanish oson, ikkinchidan, u jQuery mualliflari tomonidan yaratilgan. Kutubxona jQuery-ga asoslangan va mahalliy JavaScript kodini sinab ko'rish uchun javob beradi.

QUnit-ning so'nggi versiyasini rasmiy veb-saytdan yuklab olishingiz mumkin. Kutubxona bitta JS va CSS fayli sifatida keladi. Aytaylik, siz kerakli komponentlarni yuklashni aniqladingiz va agar shunday bo'lsa, test sinovini yozish vaqti keldi. Uzoqqa bormaylik va trim() funksiyasini sinab ko'rishga harakat qilaylik.

Sinovlarni namoyish qilish uchun men quyidagi tuzilishga ega oddiy loyihani yaratdim:

• index.html - test natijalarini ko'rsatadigan asosiy fayl;
• qunit-1.12.0.js - QUnit kutubxona fayli;
• example.js - sinov uchun kodni o'z ichiga olgan fayl (bizning holatlarimizda trim() funksiyasining tavsifi);
• test.js - testlar bilan fayl;
• qunit-1.12.0.css - testlar bilan hisobotni loyihalash uchun uslublar.

index.html va test.js fayllari mazmuni 1 va 2 roʻyxatlarda keltirilgan. Bizni koʻproq ikkinchi roʻyxat qiziqtiradi, unda sinovdan oʻtayotgan funksiya deklaratsiyasi (trim()) va uni tekshirish uchun test kodi mavjud. funksionallik. Iltimos, trim() funksiyasining o'zi istalgan joyda joylashgan bo'lishi mumkinligini unutmang; Men uni jurnalda joy tejash uchun ikkinchi ro'yxatga kiritdim.
Endi testlarning o'zlarini ko'rib chiqaylik. QUnit.js kutubxonasi bizga bir qancha usullarni taklif qiladi:

• test() - testni tavsiflash uchun o'ram;
• ok() - tasdiqlash birinchi parametrning haqiqatini tekshirishga imkon beradi. Bizning misolimizda men uni biz belgilagan trim() funksiyasiga chaqiraman va uni men kutgan qiymat bilan solishtiraman. Agar shart to'g'ri bo'lsa, sinovdan o'tgan;
• equal() - usul birinchi va ikkinchi parametrlarning tengligini tekshirish imkonini beradi. Iltimos, darhol e'tibor bering, bu usul zaif tekshiruvni amalga oshiradi, shuning uchun u faqat skalyar miqdorlar uchun mos keladi;
• notEqual() teng() ga qarama-qarshidir. Agar birinchi qiymat ikkinchisiga teng bo'lmasa, bajariladi;
• strictEqual() - teng() ga o'xshash faqat bitta farq bilan - u qat'iy tekshirishdan foydalanadi (ya'ni ma'lumotlar turini ham tekshiradi);
• notStrictEqual() - usul strictEqual();
• deepEqual() - rekursiv tasdiqlar usuli, primitivlar, massivlar, ob'ektlar uchun ishlatiladi;
• notDeepEqual() - usul deepEqual();
• rises() - bu istisnolarni keltirib chiqaradigan qayta qo'ng'iroq qilish funktsiyalarini sinab ko'rish uchun bayonot.

Ikkinchi ro'yxatda men ushbu usullarni amalda qo'llashni aniq ko'rsatdim. Agar siz ushbu shaklda test namunasini ishga tushirsangiz, barcha testlar muvaffaqiyatli o'tadi (tegishli rasmga qarang). O'tgan va muvaffaqiyatsiz bo'lgan testlar o'rtasidagi farqni ko'rish uchun men bitta test uchun kodni biroz o'zgartirdim. Men ataylab strictEqual() dan foydalanib test chizig'iga noto'g'ri natija qo'shdim (tegishli rasmga qarang).

Listing 1. Index.html faylining mazmuni QUnit bilan test qilish

Biz oddiy funktsiyalarni sinab ko'rishni saralab oldik. Qanday bo'lmasin, menda qo'shimcha hech narsa yo'q. Keyinchalik, siz haqiqiy kodni olishingiz va testlarni o'zingiz yozishga harakat qilishingiz kerak. Keling, JavaScript ishlab chiquvchilari uchun tez-tez uchraydigan yana bir vazifani ko'rib chiqaylik - asinxron funktsiyalarni sinab ko'rish. JavaScript kodi bilan to'ldirilgan dastur AJAX yordamida server tomoni bilan 99% o'zaro ta'sir qiladi. Siz bu kodni ham belgisiz qoldira olmaysiz, lekin testlarni yozish biroz boshqacha ko'rinadi. Keling, bir misolni ko'rib chiqaylik:

AsyncTest("myAsyncFunc()", funktsiya () ( setTimeout(funktsiya () ( ok(myAsyncFunc() == rost, "Ma'lumotlar muvaffaqiyatli uzatildi"); start(); ), 500); ));

Ushbu misoldan oldingisidan asosiy farq shundaki, test() o'rami o'rniga asyncTest() ishlatiladi va shu bilan men asinxron testga qiziqqanimni bevosita bildiradi. Keyin men 500 millisekundlik vaqtni ishga tushiraman. Bu vaqt ichida myAsyncFunc() funksiyasi ma'lumotlarni test serveriga o'tkazishi kerak va agar hamma narsa yaxshi bo'lsa, true qiymatini qaytaradi. Bu erda eng qiziqarli daqiqalar keladi. asyncTest() chaqirilganda, bajarilish oqimi to'xtatiladi va test tugagach, o'zini ishga tushirish kerak. Bajarish oqimini boshqarish uchun QUnit start() va stop() usullariga ega.

QUnit kutubxonasi yordamida asinxron funktsiyalarni sinab ko'rish juda oddiy. Men ko'rib chiqmoqchi bo'lgan oxirgi misol bir nechta asenkron tekshiruvlarni amalga oshiradigan test yozishni o'z ichiga oladi. Bunday muammolarda paydo bo'ladigan asosiy savol - bu ijro etuvchi ipni boshlash uchun optimal joy. Rasmiy doc shunga o'xshash narsalarni ishlatishni taklif qiladi

AsyncTest("myAsyncFunc()", funktsiya () ( wait(3); // Bu yerda biz uchta tekshiruvni bajaramiz ok(myAsyncFunc(), "Dunyoni yaxshiroq joyga aylantirish 1"); ok(myAsyncFunc(), "O'z navbatida dunyo yaxshiroq joy 2") ; ok(myAsyncFunc(), "Dunyoni yaxshiroq joyga aylantirish 3"); setTimeout(funktsiya () (start(); ), 3000); ));

Har doim esda tutishingiz kerakki, ko'plab interfeyslar JavaScript-da yozilgan. Misol uchun, foydalanuvchi pimpni bosadi va uning sekin urishiga javoban biror narsa sodir bo'lishi kerak. Loyihalarda bunday "interfeys" kodlarining juda ko'p miqdori mavjud va u ham testlar bilan qamrab olinishi kerak. Keling, qanday qilib foydalanuvchi tugmachasini bosishni taqlid qilishimiz va bu harakat uchun alohida test yozishimiz mumkinligini ko'rib chiqamiz. Tasavvur qilaylik, bizda bosilgan tugmalarni qayd qiluvchi ma'lum bir funktsiya mavjud. Men uning kodini uchinchi ro'yxatda taqdim etdim.

Ro'yxat 3. Klaviatura bosishlarini qayd qilish funksiyasi KeyLogger(maqsad) ( if (!(keyLoggerning bu misoli))) ( new KeyLogger(target); ) qaytaring this.target = target; this.log = ; var self = this; this.target. off ("keydown").on("keydown", funksiya(voqea) ( self.log.push(event.keyCode); )); )

Endi ushbu funktsiyani sinab ko'rishga harakat qilaylik. Avvalo, testning tanasida biz bosilgan tugmachani taqlid qilishimiz kerak. Buni amalga oshirishning eng oson yo'li jQuery kutubxonasi bo'lib, u sizga bir necha qator kodlarda voqea yaratish imkonini beradi (Ro'yxat 4-ga qarang).

Listing 4. KeyLogger testi uchun test kodi("Key logging test", funksiya () ( var hodisa, $doc = $(document), keys = KeyLogger($doc); event = $.Event("keydown"); voqea .keyCode = 9; $doc.trigger(voqea); teng(keys.log.length, 1, "Kalit qayd etilgan"); teng(keys.log, 9, "Yozilgan 9-kodli tugmachani bosish"); ));

Sinov ro'yxatining boshida men "tugmachani pastga" tugmachasini bosishni taqlid qilish uchun voqea tayyorlayman. Tab tugmachasini bosish bizni qiziqtiradi (kod 9). Keyin, trigger() usulidan foydalanib, men tayyorlangan hodisani yuboraman, shundan so'ng men sinovni boshlashim mumkin. Birinchidan, biz umumiy rasmni tekshiramiz - tugma bosilganmi, keyin esa uning kodi.

Qunit.js foydalanuvchi harakatlarini sinab ko'rish imkonini berganligi sababli, DOM uchun testlarni yozish ham muammo tug'dirmasligi kerak. Bu haqiqatan ham to'g'ri va quyidagi misol mening so'zlarimni tasdiqlaydi. Men bunga izoh bermayman, shunchaki kodga qarang va hamma narsa aniq bo'ladi:

Test("Yangi div elementini qo'shish", funktsiya () ( var $fixture = $("#qunit-fixture"); $fixture.append("Bu yangi div"); teng($("div", $fikstür) .length, 1, "Yangi div muvaffaqiyatli qo'shildi!"); ));

QUnit.js kutubxonasidan foydalangan holda testlarni yozish qulay va sodda, ammo ertami-kechmi ishga tushirish, sinovdan o'tkazish va natijalarni yig'ishni qandaydir avtomatlashtirish istagi sizni hayratda qoldiradi. Misol uchun, bu maqsadda DigitalOcean-da alohida virtual mashinam bor, men uni faqat konsol yordamida boshqarishim mumkin.

PhantomJS loyihasi ushbu muammoni juda oqlangan tarzda hal qilishga imkon beradi. Bu shunchaki birlik testlarini yozish uchun yana bir ramka emas, balki WebKit dvigatelining to'liq huquqli konsol versiyasidir. Oddiy qilib aytganda, ushbu ilova brauzerga taqlid qiladi. PhantomJS yordamida nafaqat testning bajarilishini tekshirishni avtomatlashtirish, balki ertami-kechmi ishlab chiquvchi oldida paydo bo'ladigan ko'plab muammolarni hal qilish mumkin: sahifani ko'rsatish natijalarini faylga (PNG, JPG), tarmoq monitori funktsiyalarini olish. (yuklash tezligi, umumiy ishlash va boshqalar), foydalanuvchi harakatlarini emulyatsiya qilish va boshqalar. Men sizga vaqt ajratib, ushbu loyiha bo'yicha rasmiy hujjatlarni o'qib chiqishingizni maslahat beraman, albatta o'zingiz uchun qiziqarli narsalarni topasiz.

PhantomJS turli platformalar uchun kompilyatsiya qilinishi mumkin (*nix, OS X, Windows). Agar siz hamma narsani Windows-da ishlab chiqsangiz, unda hech qanday muammo bo'lmaydi - ikkilik fayllarni birlashtiring va davom eting. Agar sizda ikkita video adapter o'rnatilgan bo'lsa, ulardan biri NVIDIA bo'lsa, ishga tushirishda ozgina qiyinchiliklar paydo bo'lishi mumkin. Bunday holda, siz yon panelda tasvirlangan hackdan foydalanishingiz kerak bo'ladi.

Keling, PhantomJS bilan amalda tanishishga harakat qilaylik. Oxirgi bo'limda tayyorlangan testlarni PhantomJS orqali bajarish va ijro natijalarini konsolga olish uchun bizga maxsus yuklovchi skripti kerak - run-qunit.js. Konsolni oching (men Windowsda ishlayman, shuning uchun cmd dan foydalanaman) va buyruqni formatda yozing

phantom.exe

Mening holimda ishga tushirish buyrug'i quyidagicha ko'rinardi:

E:\soft\phantomjs>phantomjs.exe E:\temp\testjsforx\qunit\run-qunit.js fayli:///E: /temp/testjsforx/qunit/index.html

Uni amalga oshirish natijasi:

Sinovlar 2592 millisekundda yakunlandi. 9 ta tasdiqdan 9 tasi o'tdi, 0 tasi muvaffaqiyatsiz.

Albatta, kodingizni testlar bilan qoplash kerak va siz yaratayotgan dastur qanday miqyosda ekanligi muhim emas. Yana bir bor eslatib o'taman: hatto eng kichik dasturlar ham qo'llab-quvvatlanishi va qo'shilishi kerak bo'lgan qo'pol hayvonlarga aylanadi. Yaxshi sinovdan o'tgan kod muvaffaqiyat va sifat kalitidir. Ha, avtomatlashtirilgan testlar uchun mos kod yozishni darhol boshlash oson emas, lekin menga ishoning, bu azoblarning barchasi kelajakda o'zini oqlaydi. Bugun menda bor narsa shu, omad tilaymiz!

Bu shunday bo'ldi, lekin men ushbu maqoladagi barcha misollarni Linuxda emas, balki eskisi ostida sinab ko'rdim yaxshi Windows 7. Ma'lum bo'lishicha, PhantomJS bir nechta video adapterlardan foydalanadigan tizimlarda ishlaganda kichik muammolarga duch keladi. O'rnatilgan video chipiga qo'shimcha ravishda, mening noutbukim ham NVIDIA-ga ega va shuning uchun PhantomJS phantom.exit() buyrug'iga javob berishdan qat'iyan bosh tortdi. Natijada, skriptni bajargandan so'ng, PhantomJS jarayoni o'z ishini yakunlamadi va xotirada osilib turishda davom etdi. Terminal oynasi ham o'chirish buyruqlariga javob berishni to'xtatdi (yordam bermadi).

Agar siz ham shunga o'xshash muammoga duch kelsangiz va Windows-da PhantomJS-dan foydalanishni rejalashtirmoqchi bo'lsangiz, quyidagi buzg'unchilikni qilishga tayyor bo'ling. NVIDIA boshqaruv panelini oching. Daraxtdagi "3D sozlamalari" bandini toping. O'ng tomonda "Afzallashtirilgan grafik adapter" variantini ko'rishingiz kerak. Avvalboshdan. uning qiymati "Avtomatik tanlash" ga o'rnatiladi. Biz uni "Yuqori unumdorlik" ga o'zgartirishimiz kerak. NVIDIA protsessori" yoki "Integratsiyalashgan grafik uskuna". Ushbu oddiy hiyladan so'ng, PhantomJS o'zini itoatkorlik bilan tuta boshladi.

Bir kuni mening bir do'stim JavaScript-ni jiddiy korporativ mahsulotlarni yozish uchun qanday ishlatish mumkinligidan hayratda qoldi, chunki unda kompilyator yo'q. Aslida, yuqori sifatli kodni yaratishda hal qiluvchi rolni dasturlash tili uchun kompilyatorga ega bo'lish emas, balki dasturiy ta'minot tizimini yaratishning to'g'ri tanlangan va yaxshi sozlangan texnik jarayoni o'ynaydi.

Bu jarayon dasturchi ishining sifati va samaradorligini nazorat qilish vositalari majmuasini o'z ichiga olishi kerak. Bunday vositalar quyidagilar bo'lishi mumkin: birlik va integratsiya testi, uzluksiz integratsiya (Continuous Integration, CI), turli ko'rsatkichlarni yig'ish va tahlil qilish (masalan, nDependda juda uzoq usullar), JsLint, FxCop talablariga muvofiqligini tekshirish va boshqalar.

Ushbu maqolada men sizga JavaScript-da mahsulotingizni avtomatik birlik va integratsiya testini qanday to'g'ri bajarish kerakligini aytmoqchiman. Aslida, bu borada JavaScript tili Java yoki C# tilidan tubdan farq qilmaydi.

Odatda, kelajakda kod o'zgartirilganda regressiya xatolari xavfini kamaytirish uchun tugallangan funksionallik uchun avtomatlashtirilgan birlik va integratsiya testlarini yaratish tavsiya etiladi. JavaScript holatida bunday testlar turli brauzerlarda tizim funksionalligini sinovdan o'tkazishni ta'minlash bosqichlarini avtomatlashtirish orqali sezilarli darajada soddalashtirishi mumkin. Bundan tashqari, mahsulotdagi har bir yopiq xato uchun birlik yoki integratsiya testini yozish yaxshi fikr bo'lishi mumkin.

Bundan tashqari, birlik testini yozish orqali mantiqni kodlashni boshlashni talab qiladigan dasturlash usullari mavjud: Test-Driven Development (TDD) va Behavior-Driven Development (BDD). Ular tez-tez Agile jarayonida qo'llaniladi. Keling, ularning xususiyatlarini batafsil ko'rib chiqaylik.

Sinovga asoslangan ishlab chiqish - bu quyidagi to'rt bosqichni takrorlaydigan kod yozishning iterativ jarayoni:

1-qadam. Mantiqning yangi qismini qo'shishdan oldin, ushbu mantiqni sinab ko'rish uchun birlik testini yarating;

2-qadam. Sinovni bajaring va shunday ekanligiga ishonch hosil qiling Yo'q o'tadi;

3-qadam. Sinovni muvaffaqiyatli o'tkazadigan eng oddiy kodni yozing;

4-qadam. Sifat talablariga javob berish uchun kodni tahrirlang, kod takrorlanishini olib tashlang va testdan o'tishini ta'minlang.

Birlik testi - bu ma'lum bir komponentning (modulning) izolyatsiya qilingan muhitda ishlashini tekshiradigan kod. Integratsiya testi sinovdan o'tadigan kodga ishora qiladi birgalikda ishlash bir nechta komponentlar. Modul boshqa modullarga bog'liq bo'lsa, izolyatsiya qilingan muhitda sinovdan o'tkazish uchun test juftlari qo'llaniladi.

Birlik testida ishlatiladigan yordamchi ob'ektlarni toifalarga bo'linishi Jerar Meszarosning xUnit Test Patterns kitobidan kelib chiqadi. Ushbu toifalar birgalikda "test dubllari" deb ataladi. O'qishning quyidagi turlari mavjud:

• soxta;
• Qo'g'irchoq.

stub chiqish qiymatlari ular uchun oldindan ko'rsatilgan. U qaram komponentning interfeysini simulyatsiya qilish uchun ishlatiladi.

Mock - yordamchi ob'ekt xulq-atvor bu oldindan belgilab qo'yilgan. U bog'liq komponentning interfeysini simulyatsiya qilish va uning to'g'ri ishlatilayotganligini tekshirish uchun ishlatiladi.

Ayg'oqchi - bu test paytida ularga berilgan usullar va parametrlarni tekshirish uchun yordamchi ob'ekt.

Soxta - bu soddalashtirilgan shaklda bog'liq komponentning interfeysini amalga oshiradigan yordamchi ob'ekt. Masalan, birlikni sinovdan o'tkazish uchun siz mahsulotning ishlab chiqarish versiyasida ishlatiladigan relyatsion ma'lumotlar bazasi o'rniga xotiradagi ma'lumotlar bazasiga ega bo'lishingiz mumkin.

Qo'g'irchoq - bu yordamchi ob'ekt bo'lib, unga havola yoki o'tish usuli imzo yoki boshqa shartnomada talab qilinadi, lekin uning haqiqiy qiymati hech qachon ishlatilmaydi.

Stub va Mock o'rtasidagi farq sinov natijalarini tekshirish usulidir. Stub holatida ob'ektning holati sinov oxirida tekshiriladi. Mock holatida test ob'ekt ro'yxatga olish paytida tasvirlanganidek ishlatilganligini tekshiradi. Tafsilotlarni Martin Faulerning "Masxaralar stub emas" yozuvida topish mumkin va men bu erda faqat bir misol keltiraman.

Funktsional talablarni amalga oshirish orqali dasturiy ta'minotni ishlab chiqishga iterativ yondashuv allaqachon tanish bo'lgan natijaga yo'naltirilgan testga asoslangan ishlab chiqish uslubidir. BDD jarayonida quyidagi uchta bosqich ketma-ket amalga oshiriladi:

1-qadam. Amalga oshirilayotgan modulga testlar shaklida funksional talablarni aniqlash;

2-qadam. Modul kodlash;

3-qadam. Ishlayotgan testlar natijalarini tekshirish orqali mijozning yoki biznes-tahlilchining () barcha istaklari bajarilganligini tekshirish.

BDD uslubida testlarni yozishda Mock ob'ektlaridan foydalanish juda qulay, chunki ular komponent uchun funktsional talablarni mukammal aks ettiradi. Shunday qilib, BDD jarayonidagi testlar muammoning (foydalanuvchi hikoyasi) Scrum shartlarida rasmiylashtirilgan tasviri bo'lib xizmat qilishi mumkin, bu esa tayyor mahsulot uchun texnik xususiyatlar va hujjatlarni yozish vaqtini tejaydi.

To'liq JavaScript birligi va integratsiyani tekshirish vositasi quyidagi komponentlardan iborat bo'lishi kerak:

• Tasdiqlash kutubxonasi (har bir test oxirida komponentning holatini tekshirish usullari to'plami);
• Soxta kutubxona (soxta ob'ektlar va boshqa "dublikatlarni" yaratish uchun vosita);
• Sinov yuguruvchisi (asbob avtomatik ishga tushirish ko'pgina brauzerlarni qo'llab-quvvatlaydigan testlar, shu jumladan iOS brauzerlari va Android);
• ga ulanish bloki mashhur tizimlar uzluksiz integratsiya (Continuous Integration).

Bugungi kunda JavaScript kodini sinovdan o'tkazishning uchta strategiyasi mavjud (batafsil ma'lumot uchun Kristian Yoxansenning JavaScript-ni sinovdan o'tkazish kitobining uchinchi bobiga qarang):

• Brauzer ichidagi test;
• Boshsiz sinov;
• JsTestDriver yo'li bo'ylab sinov.

Brauzer ichidagi test ishlab chiquvchi ochadigan HTML sahifasidan barcha birlik va integratsiya testlarini o'tkazishni o'z ichiga oladi. kerakli brauzerlar o'z-o'zidan. Ushbu yondashuv oddiy va intuitivdir. Biroq, uning kamchiligi shundaki, u bunday testlarni Uzluksiz integratsiyaga kiritish imkoniyatini nazarda tutmaydi. Bundan tashqari, HTML-sahifani o'n yoki undan ortiq brauzerda qo'lda ishga tushirish va doimiy ravishda "F5" tugmasini bosish ishlab chiquvchi uchun zerikarli bo'lishi mumkin.

Boshsiz test barcha JavaScript kodlari Java, Ruby, JavaScript, C++ va boshqalarda yozilishi mumkin bo'lgan emulyatorda sinovdan o'tkazilishini anglatadi. Bugungi kunda eng mashhur emulyator bu PhantomJS bo'lib, u buyruq satridan ishlaydigan WebKit dvigatelidir. Emulyatorning afzalliklari orasida uni doimiy integratsiyada osongina ishlatish mumkinligini, shuningdek, buyruq satridan barcha testlarni ishga tushirishni avtomatlashtirishga imkon berishini ta'kidlash mumkin. Biroq, bu yondashuv sezilarli kamchilikka ega - kod haqiqiy brauzerlarda sinovdan o'tkazilmaydi, shuning uchun emulyatorda takrorlanmaydigan brauzer xatolarining yo'qolishi xavfi mavjud. JsTestDriver paydo bo'lishidan oldin, In-Browser testi boshsiz test bilan birlashtirilganligini tez-tez ko'rish mumkin edi, chunki ular bir-birini mukammal ravishda to'ldiradi.