Що слід перевірити в Javascript?

На роботі ми нещодавно запустили додаток на базі Javascript (фактично використовуючи Coffeescript, але все ж), з якого я впроваджував автоматизовану тестову систему з використанням JsTestDriver та тканини.

Ми ніколи не писали щось з таким Javascript, тому до цих пір ми ніколи не робили тестування Javascript. Я не впевнений, що саме ми повинні тестувати в наших одиничних тестах. Ми писали плагіни JQuery для різних речей, тому цілком очевидно, що їх слід перевірити на правильність якнайбільше за допомогою JsTestDriver, але всі інші в моїй команді, здається, вважають, що нам слід також перевіряти рівень сторінки на Javascript.

Я не думаю, що ми повинні тестувати Javascript на рівні сторінки як одиничні тести, але замість цього використовувати систему на зразок Selenium, щоб перевірити, чи працює все так, як очікувалося. Моє основне міркування для цього полягає в тому, що на даний момент тести Javascript на рівні сторінки гарантовано закінчуються через JsTestDriver, оскільки вони намагаються отримати доступ до елементів DOM, які не можуть існувати.

Отже, що повинно бути перевіреним у Javascript?

javascript testing unit-testing

— Натан Хоуд
джерело

Ви ізолюєте будь-який код JavaScript, записаний у модулі. Потім ви просто протестуєте входи та виходи цих модулів. Будь-які модулі, які мають справу з DOM, означають, що ви повинні протестувати DOM. Скористайтеся кращим інструментом, а потім jsTestDriver.

— Райнос

Ви маєте перевірити бізнес-логіку. Якщо ваша бізнес-логіка та елементи DOM переплітаються, то у вас є вада дизайну. Абстрагуйте якомога більше ділової логіки з елементів сторінки, щоб можна було її правильно перевірити. Для перевірки взаємодії елементів DOM ви повинні використовувати Selenium.

— maple_shaft

@NathanHoad Ви пишете одиничні тести, які запускаються в самому браузері, nodeunit, qunit і жасмін - це розумні інструменти. Під час роботи в браузері у вас є DOM. Ви можете використовувати такий інструмент, як тестування, для автоматизації тестування браузера.

— Райнос

Дякую. Я дивився на jsTestDriver, оскільки він стверджував, що може працювати в браузері, що, хоча це технічно вірно, я виявив, що не те, що працювати з QUnit. Наразі я працюю над власним інструментом, який використовує QUnit, із спеціальною панеллю налагодження Django. Використовуючи Selenium, я зможу виявити невдалі тести. Також я сумніваюся, що мій начальник заплатив би за тестування, хоча це виглядає досить добре!

— Натан Хоуд

пов’язано: Як ви перевіряєте свій JavaScript

— gnat

Відповіді:

Перевірте все, що можете.

Чисту логіку можна легко перевірити.

Якщо ваш код взаємодіє з DOM або мережею, це набагато складніше.

Якщо ви можете абстрагувати фрагмент коду для роботи над довільним елементом DOM замість конкретного, ви можете протестувати його легше. (Зробіть елемент для роботи над параметром).

Код, який використовує Ajax, можна перевірити, просто зателефонувавши до функції зворотного дзвінка з фіксованими даними. У мене були кілька тестів, де я переписав $.ajaxсвою функцію. Просто переконайтеся, що ви поклали справжній назад, коли закінчите!

Що ви знайдете, це те, що "JavaScript на рівні сторінки" насправді означає "щільно пов'язаний код", і якщо ви роз'єднаєте частини коду, ви можете перевірити їх самостійно.

(Селен не є одиничним інструментом тестування. Він відмінно підходить для сценаріїв високого рівня, але ви не можете провести тест-драйв з ним, і він не працює в ізольованому середовищі.)

— Шон Макміллан
джерело

Жасмін може знущатися з функцій викликів та даних відповідей, ви можете розглянути це замість переважних функцій.

— Стів

Я повинен уточнити - у нас є функції і такі на кожній сторінці. Я говорив більше про тестування коду, який виконується всередині $(document).ready(...).

— Натан Гуад

Це все питання наскільки це велике .... :-) Я відчуваю, що ви повинні мати можливість звести це до однієї іменованої функції, яка також перевірена. Тоді ваш неперевірений код - це один рядок. (Тепер це мета, а не задана. На практиці у мене завжди було більше одного рядка неперевіреного коду.)

— Шон Макміллан

@SeanMcMillan - мені складно перевірити частини програми, яка впливає лише на DOM, наприклад, функцію, яка прив'язує лише кілька подій до деяких елементів DOM. Як би ви переконалися, що ці події були написані належним чином? не тестування одиничних тестів, а справжнє натискання та перевірка браузера (з використанням селену чи будь-чого іншого)

— vsync

@vsync: Ви можете перевірити, що, скажімо, обробник кліків був приєднаний до даного елемента DOM досить легко. Я не думаю, що можливо перевірити, що "click" - це правильний обробник, і що ви додали його до потрібного елемента.

— Шон Макміллан

Алгоритми тестування. Частини, пов'язані з графічним інтерфейсом, більше залежать від конкретного браузера, тому їх потрібно протестувати за допомогою утилів, подібних до селену.

Ваш код, звичайно, повинен містити алгоритми як окремі фрагменти коду, якщо цього немає, то тестування одиниць майже неможливо.

Плагіни jquery, btw, непрості для перевірки одиниці.

— Сергій Столяров
джерело

Всі хороші бали! Я погоджуюся, що вони також не легко перевіряються, залежно від того, як вони написані.

— Натан Хоуд

-1

Раніше я працював з Java, і те, що я бачу, тестування одиниць Java простіше, ніж тестування одиниць JavaScript, оскільки Java більш жорстка.

Мене продають на тій тестовій розробці - це найкраще, тому я також вивчаю, як використовувати тестовий JavaScript. У Java я знущався з коду, який підключився до бази даних, Об'єктів доступу до даних, і я порівнюю це з кодом у JavaScript, який змінює DOM і код, який робить AJAX дзвінки на сервер.

Що я отримую, це те, що мені здається, що те, що слід перевірити, - це явна логіка. Наприклад, ви не хочете робити AJAX-дзвінок під час запуску одиничних тестів, оскільки (а) вам потрібен запуск сервера і (б) це повільно, і одне з керівних принципів тестування одиниць полягає в тому, що це потрібно супер швидкий, щоб розробники не уникали запускати їх, як щохвилини.

Ще одне керівництво - процес безперервної інтеграції надсилати електронне повідомлення про те, що він знайшов тест блоку, який не вдався.

— SBel
джерело