Должен я модульный тест мой JavaScript?
Мне любопытно к тому, если бы это было бы ценно, я хотел бы начать использовать QUnit, но я действительно не знаю, где начать. На самом деле я не собираюсь лежать, я плохо знаком с тестированием в целом, не только с JS.
Я надеюсь получить некоторые подсказки к тому, как я начал бы использовать поблочное тестирование с приложением, которое уже имеет большую сумму JavaScript (хорошо так приблизительно 500 строк, не огромных, быть достаточно, чтобы заставить меня задаться вопросом, есть ли у меня регрессия, которая остается незамеченной). Как Вы рекомендовали бы начать и Где я запишу свои тесты?
(например, его приложение для направляющих, где логическое место состоит в том, чтобы иметь мои тесты JS, было бы здорово, если они могли бы войти /test каталог, но это вне общедоступного каталога, и таким образом не возможный... допускают ошибку, это?)
5 ответов
] Ну, начните с [] JsUnit[]. Однако, похоже, что юнит-тестирование интересует вас в целом больше.[
] [] Юнит-тестирование (если оно выполнено правильно) дает следующие результаты:[
] [- ]
[
- ]Способность обнаруживать регрессии в вашем коде, как вы уже упоминали[ ] [
- ]Менее наглядная интеграция, так как каждый фрагмент вашего кода уже проверяется сам по себе[ ] [
- ]Четкая картина того, как ваш код ожидается (и не ожидается) быть использован[ ] [
]Юнит-тестирование должно в основном касаться любого []публичного[] метода в вашем коде. Иногда у вас могут быть причины тестировать частные методы, и я уверен, что вы можете решить, когда это может произойти. Цель проста:[
] [- ]
[
- ]Тестировать, что метод делает правильные вещи с правильным вводом[ ] [
- ]Тестировать, что метод делает правильные вещи с вводом []wrong[].[ ] [
]Во многих отношениях ваши тесты должны определять функциональность ваших методов.[
] []Иногда, когда люди пишут свои юнит-тесты, они намеренно "вырезают" любой интегрированный код (т.е. вызов метода, который возвращает другие данные из базы данных, файла или бизнес-логики) и заставляют их вместо этого возвращать статические данные. Это помогает вам почувствовать себя более уверенным в том, что вы тестируете только тот код, который присутствует в тестируемой логике.[
] [] Для получения более подробной информации о хороших и плохих методах юнит-тестирования можно почитать [] на [].[
] [][]Правка:[] Я не очень много знаю о том, как это делать в Ruby on Rails, но вы можете подумать о том, чтобы посмотреть, что делают [] некоторые другие люди []. В конечном итоге, доступные вам инструменты и структура ваших тестов [] будет [] зависеть от вашего фреймворка и языка.[
].Тестирование JavaScript напрямую не является тривиальным (поскольку ему нужен "внешний" интерпретатор, которым в производстве env является браузер). Так же сложно включить его в среду Continous-интеграции.
Так как юнит-тестирование JavaScript - это очень большое усилие, я бы склонялся к тестированию вещей более грубых, чем интеграционные тесты. Например: canoo-webtest включает в себя интерпретатор java-скриптов. Вы подделываете действия пользователя (например, нажимаете кнопку), и запускается javascript. Таким образом, вы тестируете косвенно.
Тем не менее, есть некоторые связанные с интерфейсом javascript вещи (например, fade-эффекты) и т.д... Это нужно проверить вручную.
] Одним из лучших руководств по включению тестирования в старый код является [] Эффективная работа с кодом наследия []. В вашем случае, у вас нет большого количества кода, о котором вам необходимо позаботиться самостоятельно. Просто начните класть его туда, куда можно, и подумайте о том, как легче структурировать код, чтобы позволить тестирование в целом.[
].Я обнаружил, что модульное тестирование с использованием javascript очень полезно. Модульное тестирование компенсирует отсутствие безопасности типов в языке. Это также позволяет вам быстро проверить ваш код, работающий в разных браузерах.
Для своих тестов я использую QUnit как средство запуска тестов и JSMock для имитации. Я использую firebug для их отладки.
Существует меньше образовательных ресурсов для обучения тестированию на Javascript, чем, скажем, C # или Java. Вещи тестируются по-другому, потому что это динамический язык ... Возможно, лучше начать тестирование на C # или Java.
Я не очень хорошо разбирался в написании модульных тестов, пока не прочитал материал на www.xunitpatterns.com. Так что, если вы только начинаете, я бы посоветовал купить книгу и прочитать ее.
С Rails я бы рекомендовал Blue Ridge . Это пакет ScrewUnit, некоторые rake-задачи, а также возможность запускать тесты из браузера (через Rhino). У нас уже есть несколько тестов Javascript. Тесты больше похожи на RSpec, чем на другие упомянутые инструменты, так что это меньшее изменение мышления ... отлично работает!
Для начала лучше всего начать копаться в сети в поисках других людей, которым это удалось. Примеры есть на github.