Тестирование JavaScript, который Управляет DOM
Это действительно зависит, если Вы говорите о ASP.NET или Классическом ASP. При использовании ASP.NET нет многих серьезных оснований для использования JavaScript.
Классик ASP является различным случаем. Можно использовать JavaScript на стороне сервера в ASP просто тот же способ, которым Вы использовали бы VBScript. Можно получить доступ к Приложению, Серверу, Запросу и объектам Ответа все равно как через VBScript.
может быть реальная выгода для использования JavaScript на стороне сервера в ASP, а не VBScript. Это означает, что можно совместно использовать код между кодом браузера и серверным кодом. Это также означает, что Ваши разработчики не должны иметь дело с двумя различными языками.
существуют некоторые оборотные стороны к стороне сервера JavaScript в ASP все же. Во-первых это, кажется, не с такой скоростью, как VBScript на стороне сервера при конкатенации строк. Это также не столь хорошо как совершение звонков к COM-объектам как VBScript (можно только вернуть данные из вызовов COM через возвращаемое значение, а не через out/byref параметры).
4 ответа
Я обнаружил, что тесты Javascript / DOM, особенно для простых взаимодействий, которые вы описываете, не так полезны. Вы будете проверять, все ли настроено правильно, и, поскольку jQuery настолько декларативен, ваши тесты очень похожи на ваш код.
Мое текущее мнение таково, что если вы пишете более крупные JS-компоненты, имеет смысл вытащить набор взаимосвязанных поведений как в плагин jQuery, так и в набор тестов для него.
Но из примеров, которые вы упомянули, похоже, что вы действительно ищете уровень защиты на своем интегрированном веб-сайте. Такой инструмент, как Selenium, вероятно, будет более мощным и подходящим для вас. В частности, он
- может быть автоматизирован,
- может работать в нескольких браузерах, включая IE
- , запускаемый в контексте вашего веб-приложения и страниц, так что drag-n-drop можно протестировать там, где это действительно происходит, а не в какой-то тестовой среде.
- AJAX можно протестировать
В дополнение к тому, что говорит Джейсон Харвиг, я бы сказал, что модульное тестирование - это тест, позволяющий убедиться, что код выполняется должным образом. Если вы хотите это проверить, то Джейсон абсолютно прав в том, как вы должны это делать. Если вы хотите запустить тесты, чтобы проверить, что происходит манипуляция с DOM (тестирование пользовательского интерфейса), а не фактический код, который выполняет манипуляции с DOM (модульное тестирование), тогда вы можете проверить что-то вроде Selenium , WatiN или Watir .
Я предполагаю, что многие люди тестируют визуально: т.е. они смотрят на вывод своего браузера на своем мониторе, чтобы увидеть, выглядит ли так, как будто DOM манипулировали должным образом.
Если это должен быть автоматизированный тестовый пример (например, для регрессионного тестирования), возможно, они записывают результат (например, снимок экрана) и делают что-то вроде сравнения двух снимков экрана, чтобы увидеть, совпадают ли результаты.
Вместо того, чтобы делать снимок экрана, вы можете просто сделать снимок всей модели DOM и провести параллельное сравнение захваченных деревьев DOM (что может быть менее подвержено ошибкам, чем сравнение пикселей).
Вместо тестирования функции JQuery css. Ваш тест должен имитировать функцию css и гарантировать, что она вызывается только один раз с правильным цветом. Тестируемый код должен быть вашим, а не фреймворком.