Тестирование Javascript, который управляет DOM

Я искал в javascript test suites, и я нашел помощью QUnit быть очень интересным. Я понимаю, как проверить вычислительный код, но.....

как вы тестируете приложения javascript, написанные в основном для манипуляции DOM?

похоже, что тестирование позиции/цвета / и т. д. элементов DOM будет спорным, потому что вы в конечном итоге сделаете что-то вроде этого:

$("li.my_element").css("background-color", "#f00");

и тогда в вашей тест...

$(function() {
    module("coloring");
    test("test_my_element", function() {
        var li_element_color = $("li.my_element").css('background-color');
        equals(li_element_color, "#f00");
    });
});

это просто не кажется правильным, потому что он в основном просто делает это:

var my_li= $("li.my_element");
my_li.css("background-color", "#f00");
if ( my_li.css("background-color") == "#f00" ) {
    return true;
}

я спятил? Как это сделать?

редактировать: вопрос:

Я думаю, что я имею в виду, мне нужно убедиться, что код не сломан перед развертыванием, но подавляющее большинство из них-помощники UI и ajax. Как проверить, что все выглядит правильно?

несколько примеры:

  • проверьте, что диалоговое окно jQuery UI появляется поверх всех других элементов
  • проверьте, что drag-n-drop работает правильно
  • проверьте, что цвет droppable изменяется, когда элемент падает на него
  • проверьте, что ajax работает правильно
  • проверьте, что нет никаких посторонних запятых, которые нарушат IE

5 ответов


Я обнаружил, что тесты Javascript/DOM, особенно для простых взаимодействий, которые вы описываете, не так полезны. Вы проверите, что все настроено правильно, и поскольку jQuery настолько декларативен, ваши тесты очень похожи на ваш код.

мое текущее мышление заключается в том, что если вы пишете большие компоненты JS, имеет смысл вытащить набор взаимосвязанных поведений как в плагин jQuery, так и в набор тестов для него.

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

  • можно автоматизировать
  • может работать с несколькими браузерами, включая IE
  • работает в контексте вашего веб-приложения и страниц, поэтому drag-n-drop можно протестировать там, где это действительно происходит, а не в какой-то тестовой среде.
  • AJAX может быть проверено

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


в дополнение к тому, что говорит Джейсон Харвиг, я бы сказал, что модульное тестирование-это тест, чтобы убедиться, что код выполняется так, как ожидалось. Если вы хотите проверить это, то Джейсон абсолютно прав о том, как вы должны это сделать. Если вы хотите запустить тесты, чтобы проверить, что происходит манипуляция DOM (тестирование пользовательского интерфейса), а не фактический код, который выполняет манипуляцию DOM (модульное тестирование), то вы можете проверить что-то вроде селен, WatiN или Watir.


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

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

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


Я тестирую AJAX вещи, как это:

  1. сделать вызов AJAX
  2. настройка таймера JavaScript
  3. Проверьте DOM, чтобы увидеть, произошли ли ожидаемые изменения

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