Что должно быть проверено в Javascript?

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

Мы никогда не писали что-либо с таким большим количеством 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 и jasmine - разумные инструменты. При запуске в браузере у вас есть DOM. Вы можете использовать такой инструмент, как тестирование, для автоматизации тестирования браузера.

— Райнос

Благодарю. Я смотрел в сторону jsTestDriver, поскольку он утверждал, что может работать в браузере, что, хотя я обнаружил, технически верно, не то же самое, что работа с QUnit. В настоящее время я работаю над своим собственным инструментом, использующим QUnit, с настраиваемой панелью инструментов отладки Django. Используя Selenium, я смогу обнаружить провальные тесты. Кроме того, я сомневаюсь, что мой босс заплатит за тестирование, хотя это выглядит довольно хорошо!

— Натан Хоад

по теме: Как вы тестируете свой javascript

— gnat

Ответы:

Проверьте все, что можете.

Чистая логика может быть легко проверена.

Если ваш код взаимодействует с DOM или сетью, это намного сложнее.

Если вы можете абстрагировать кусок кода для работы с произвольным элементом DOM вместо определенного, тогда вы можете протестировать его проще. (Сделать элемент для работы с параметром).

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

Что вы обнаружите, так это то, что «javascript уровня страницы» действительно означает «тесно связанный код», и если вы отделите части кода, вы можете протестировать их независимо.

(Selenium не является модульным средством тестирования. Он отлично подходит для сценариев высокого уровня, но вы не можете протестировать его, и он не работает в изолированной среде.)

— Шон Макмиллан
источник

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

— Стив

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

— Натан Хоад

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

— Шон Макмиллан,

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

— vsync

@vsync: Вы можете проверить, что, скажем, обработчик кликов был довольно легко прикреплен к данному элементу DOM. Я не думаю, что можно проверить, что «щелчок» является правильным обработчиком, и что вы прикрепили его к нужному элементу.

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

Тестовые алгоритмы. Части, тесно связанные с GUI, в большей степени зависят от конкретного браузера, поэтому должны быть протестированы с использованием утилит, подобных селену.

Ваш код, конечно, должен содержать алгоритмы в виде отдельных частей кода, если этого не происходит, то модульное тестирование практически невозможно.

JQuery плагины, кстати, не так просто для тестирования юнитов.

— Сергей Столяров
источник

Все хорошие моменты! Я согласен с тем, что они не так легко тестируются, в зависимости от того, как они написаны.

— Натан Хоад

-1

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

Я уверен, что разработка на основе тестирования - лучшая вещь, поэтому я также изучаю, как выполнить модульное тестирование JavaScript. В Java я смоделировал код, который установил соединение с базой данных, объектами доступа к данным, и сравнил его с кодом в JavaScript, который изменяет DOM, и кодом, который делает AJAX-вызовы на сервер.

Я имею в виду, что мне кажется, что следует проверить логику в явном виде. Например, вы не хотите делать AJAX-вызов при запуске модульных тестов, потому что (а) вам нужен сервер, и (б) он медленный, и одно из правил модульного тестирования состоит в том, что он должен быть очень быстро, чтобы разработчики не старались запускать их как каждую минуту.

Еще одно руководство для процесса непрерывной интеграции - отправить электронное письмо, в котором говорится, что он нашел модульный тест, который не прошел.

— SBel
источник