компоненти. Тестування-консоль

поточна версія vs. v1

Компоненти можна тестувати в консолі як звичайні node.js модулі. На жаль, до поточної версії у цьому випадку є проблеми із використанням залежностей, наприклад, зав'язаних на DOM. Тобто якщо я тестую компонент до консолі, запускаючи, скажімо node node mocha . я не можу просто зробити require інший компонент, зав'язаний на DOM. У будь-якому випадку в консолі require підхопить модуль node.js, а не компоненту. А у модулі domify node.js немає об'єкта document. У майбутніх версіях білдера компонент ситуація зміниться. https://github.com/component/component/issues/41. Поки що для тестування цих компонентів у консолі можна використовувати phantom.

У поточній версії доводиться використовувати (причому в тілі компоненти, але для цілей тестування) щось на зразок (див. component/router ):

Я на цьому не зупинятимуся, почекаємо v1. У цьому посту спочатку подивимося, як влаштовано юніт-тестування компонентів на низькому рівні, тобто. вручну, потім я напишу про автоматизацію цього процесу. Про інтегральне тестування js-додатків теж написано багато, я на цьому також зупинятись не буду.

Прості компоненти, які мають відмінностей (крім обгортки) від паралельного node-модуля, такі як, наприклад component/indexof , component/each , використовувати як залежності можна вже зараз, mocha-тести в консолі працюватимуть.

юніт vs. інтегральні тести

Що таке інтегральний тест зрозуміло - ми тестуємо сам додаток, в бойовій позиції (якщо відволіктися від stubs & mocks). Ми використовуємо Cucumber, Selenium, Capybara і дивимося, щоб відгук програми як цілого відповідав очікуванням. Юніт-тест це тест окремого методу в компоненті. Викликається тільки цей метод, і якщо торкається щось ще, то цепогано. Таке ось доморощене визначення. Компоненти, втім, саме так і проектуються. Вони мають внутрішні функції, недоступні зовні, і вони, природно, недоступні й у тестування. І експортовані методи, які ми цілком здатні викликати звідки завгодно.

test/test.js

Створимо найпростішу компоненту для консольного тесту. Нехай нам треба дізнатися, скажімо, наступну букву. Ми забули, що йде слідом за — г або д . Чи, скажімо, за ξ — η чи λ ? (Цей «іграшковий» метод підходить лише для символів без акцентів).

Нехай у компоненті ми будемо два методи, sym для перетворення символу, і word — для слова. У ньому скористаємося готовою компонентою component/map для зручності.

у компоненті має бути лише

рядок if (!(this instanceof example)) return new example() є магічним заклинанням, що означає, що нам не потрібно буде писати оператор new під час виклику компоненти.

package.json, mocha & should

Тепер ми використовуємо по суті не компоненти, а node.js, так що створимо файл package.json

у файлі package.json вкажемо необхідні нам залежності

map-component необхідна як приклад залежності роботи компоненти, а mocha і should — до виконання тестів.

makefile & test.js

щоб не викликати тести в консолі руками, у фалі Makefile запишемо пункт test;

mocha за замовчуванням шукає випробування в директорії test. Створимо файл test.js

Однак компоненти призначені для роботи у браузері. Тож і тестування в консолі — скоріше виняток. Тестування повинно проводитись у браузері, та бути зручним. Див. розділи.

Хардкорна конфа за С++. Ми запрошуємо лише профі.

---