Должен ли я тестировать мой JavaScript?

Question

Мне интересно, если это будет полезно, я бы хотел начать использовать QUnit , но я действительно не знаю, с чего начать. На самом деле я не собираюсь лгать, я новичок в тестировании в целом, не только с JS.

Я надеюсь получить несколько советов о том, как начать использовать модульное тестирование с приложением, в котором уже есть большое количество JavaScript (хорошо, так что около 500 строк, не очень больших, достаточно, чтобы я задавался вопросом, есть ли у меня регрессия) что остается незамеченным). Как бы вы порекомендовали начать и где мне написать свои тесты?

(например, его приложение rails, где есть логическое место для моих JS-тестов, было бы здорово, если бы они могли перейти в каталог /test, но он находится вне общедоступного каталога и, следовательно, это невозможно ... ошибаешься?)

Answer 1

Ну, начнем с JsUnit . Похоже, что вам больше интересно узнать о модульном тестировании.

Что вы получаете от юнит-тестирования (если все сделано правильно):

• Возможность обнаружения регрессий в вашем коде, как вы упомянули
• Менее болезненная интеграция, поскольку каждый фрагмент вашего кода уже протестирован сам по себе
• Четкая картина того, как ваш код ожидается (и не ожидается) будет использоваться

Модульные тесты должны касаться любого публичного метода в вашем коде. Иногда у вас может быть причина для тестирования частных методов, и я уверен, что вы можете решить, когда это может быть. Цель проста:

• Проверьте, что метод работает правильно с правильным вводом
• Проверьте, что метод работает правильно с ошибкой .

Во многих случаях ваши тесты должны определять функциональность ваших методов.

Иногда, когда люди пишут свои модульные тесты, они намеренно «заглушают» любой интегрированный код (то есть вызовы методов, которые возвращают другие данные из базы данных, файла или бизнес-логики) и заставляют их вместо этого возвращать статические данные. Это помогает вам чувствовать себя более уверенно, что вы тестируете только код, присутствующий в логике, которую вы тестируете.

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

Редактировать: Я не знаю много об этом в Ruby on Rails, но вы могли бы взглянуть на то, что делают другие люди . В конечном счете, доступные вам инструменты и структура ваших тестов будут зависеть от вашей среды и языка.

Answer 2

Я считаю, что модульное тестирование с использованием JavaScript очень полезно. Модульное тестирование компенсирует отсутствие безопасности типов в языке. Это также позволяет вам быстро проверить ваш код, работающий в разных браузерах.

Для своих тестов я использую QUnit в качестве тестового бегуна и JSMock для насмешек. Я использую Firebug для их отладки.

Существует меньше образовательных ресурсов для тестирования обучения в Javascript, чем C # или Java. Вещи тестируются по-разному, потому что это динамический язык ... Может быть, лучше начать тестирование в C # или Java.

На самом деле я не стал эффективно писать модульные тесты, пока не прочел материал на www.xunitpatterns.com. Поэтому, если вы только начинаете, я бы сказал, купите книгу и прочитайте ее.

Answer 3

С Rails я бы порекомендовал Blue Ridge . Это пакет ScrewUnit, некоторые грабли, а также возможность запуска тестов из браузера (через Rhino). У нас довольно много Javascript-тестов. Тесты больше похожи на RSpec, чем другие упомянутые инструменты, так что это меньше сдвиг в мышлении ... отлично работает!

Чтобы начать, лучшее место для этого - просто покопаться в интернете для других людей, которым это удалось. На github есть примеры.

Answer 4

Непосредственное тестирование JavaScript не является тривиальным (потому что ему нужен «внешний» интерпретатор, который в среде env является браузером). Кроме того, поэтому его трудно включить в среду непрерывной интеграции.

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

Тем не менее, есть некоторые вещи, связанные с пользовательским интерфейсом (например, эффекты затухания) и т. Д. Это нужно проверить вручную.

Answer 5

Одно из лучших руководств по внедрению тестирования в старый код: Эффективная работа с устаревшим кодом . В вашем случае у вас нет большого количества кода, о котором вам нужно беспокоиться. Просто начните размещать его там, где сможете, и подумайте о том, как легко вы могли бы структурировать свой код для общих тестов.