Pull to refresh

Comments 31

UFO just landed and posted this here
UFO just landed and posted this here
Так вам и надо — благодаря мне у вас разовьются новые чувства, призванные заменить устаревшее зрение!
После того как скачаете jsFUnit-2.1.zip, распакуйте его в public_html вашего веб-проекта. У вас появится каталог public_html/tests. Надеюсь, что все читатели осведомлены, что такое public_html. Но для тех, кто случайно начал читать статью, предлагаю взять виндовую машину, установить на неё xampp из www.apachefriends.org/en/xampp.html в c:\xampp и распаковать jsFUnit-2.1.zip в c:\xampp\htdocs.

Надеюсь, все писатели осведомлены, что можно короче — DocumentRoot.

time — необязательный параметр. Задаёт время ожидания загрузки страницы в фрейм. По умолчанию — 5000 микросекунд

Нанотехнологии? Date::getTime() оперирует миллисекундами.
Интересно, сколько писателей прочитает мою статью?

Ну а так вы правы — это в милисекундах.
скорость выполнения тестов с селениумом сравнивали? было б интересно посмотреть на результаты.
В Selenium для каждого теста перезапускался браузер.

Задержка при открытии окна составляла на Seleron 2.66 ГГц/500 ОЗУ около 5 секунд.

В jsFUnit и jsUnit задержка составляет ок. 2 сек.
а зачем перезапускать браузер дял каждого теста?
Так устроен Selenium. Надо бы спросить у его разработчиков.
а разве нельзя повесить браузер на глобальную переменную и во всех тестах ее использовать? или просто аттачить окно с браузером в каждом тесте?
Скажите, а как тестировать более сложные юзкейзы, доступные для тестов, например, в том же Selenium?
«Функционального тестирования» в приведенном описании минимум (получить окно/фрейм, нажать кнопку, открыть ссылку и еще несколько). Аналогичным образом можно использовать тот же проверенный jsUnit, тем более когда в качестве селектора разработчик должен писать не сам селектор, а команду win.document.getElementById(...). В чем отличительные особенности вашей разработки от Selenium, где выигрышь? Скажем так, скорость выполнения тестов Selenium нормальная, выполнять тесты за 1 минуту и за 50 секунд обычно разницы большой не имеет, а вот функционал тестов — критический момент.
UFO just landed and posted this here
Как пример, элементарный юзкейз: закрыть окно браузера, открыть новое окно, открыть тестируемую страницу, проверить сессию.

Как это можно осуществить с помощью описанной библиотеки, которая «не требует ничего, кроме браузера»?

«гораздо быстрее Селениума» — скорость чего вы имеете в виду?
> Как пример, элементарный юзкейз: закрыть окно браузера, открыть новое окно, открыть тестируемую страницу, проверить сессию.

С помощью библиотеки — никак, а используя библиотеку и уже встроенные возможности:

win.close() // закрываем окно
win = open("/login") // открываем в новом окне страницу

require(«translate.js») // подключаем модуль с функцией cookies
sleep(1000) // ждём пока загрузится translate.js

assetEquals( cookies().session, 'xxxx' ) // проверяем сессию
Повторюсь: «гораздо быстрее Селениума» в чем? И конкретно, для примера, который вы только что привели, выигрышь в скорости за счет чего при очень малом функционале библиотеки?
UFO just landed and posted this here
Не могу с вами согласиться, что время затраченное на тест менее критично чем функционал.

Возьмём среднестатического разработчика.
Вот он пришёл на работу написал тест и запустил его. Тест выдал ошибку. Разработчик написал код. Запустил опять тест.

Пока тест выполняется разработчик пишет другой тест или код.

Но вот прошло пару часов. Близится время обеда. Внимание разработчика рассеевается…

И уже так легко переключаться между задачами не удаётся. Разработчик сидит и ждёт пока выполнится тест.

Допустим, что у разработчика много мелких задач и он пишет код 1 минуту, а затем запускает тест.

Рассеяно внимание у разработчика 4 часа в день.

Тест выполняется 1 минуту.

Таким образом разработчик теряет четверть рабочего времени (половину вышеуказанных 4 часов).

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

4*60*60/(60+50) ~ 131 раз за эти 4 часа разработчик запустит тест для 50 сек
4*60*60/(60+60) = 120 раз для 60 сек
((60+50)*131 — (60+50)*120)/60 ~ 20 минут

За неделю — час двадцать
За месяц — 7 с половиной часов — почти рабочий день!

Согласен — время тратится и на написание тестов. Так что логичнее было бы их, как в selenium, нащёлкивать.
Но jsFUnit будет развиваться и в этом направлении без привязки к браузеру. Selenium же привязан к мозилле.

Кто на ком стоял? Потрудитесь излагать свои мысля яснее (с).

Какая-то вода о среднестатистическом разработчике в жидком вакууме тесте на 2 часа в 1 минуту.

Что касается нащелкивания, то упаси вас Столлман, Selenium кроссбраузерен. Selenium IDE — да, но никто не мешает писать тесты руками.
Тогда разницы нет — что selenium, что jsUnit
«Возьмём среднестатического разработчика»

тогда я возьму jsUnit/Selenium. Вопрос закрыт.
В jsUnit вам придётся писать руками путь к тесту.

А в jsFUnit выбор теста — через выпадающий список.

В jsUnit в случае хоть одной ошибки весь ползунок закрашивается в красный цвет.

В jsFUnit — в красный цвет закрашивается толко часть ползунка отвечающая за этот тест.
Если цвет ползунка и путь руками — основные достоинства библиотеки, то выбирать не приходится.
А серьезные приемочные/функциональные тесты пишутся руками всегда, да, на Selenium RC.
Судя по вашему высказыванию на других движках пишут одни дилетанты. А профессионалы выбирают жутко медленный Selenium :)

Главное преимущество — скорость.
В вашем примере выше о проверке кукисов скорость будет играть колоссальную роль :)
Ошибаетесь! Пример-то выбирали вы! :-)
UFO just landed and posted this here
Для начала неплохо, но есть несколько настоятельных советов: 1) уберите разноцветные jsFUnit — воспринимается как навязчивая реклама, приведёт к минусам только за это.
2) приведите цветовое форматирование и отступы к общепринятым нормам (обычно ещё в blocquote оборачивают код, тогда он не распадается), иначе наберёте за него минусов.
3) спеллчекер используйте — ошибок очень много (милисекунд, завершиться).
4) > document.all.reason.value — Вы по какому учебнику учили javascript? В курсе, что это некроссбраузерно?
4) > document.all.reason.value — Вы по какому учебнику учили javascript? В курсе, что это некроссбраузерно?

В курсе. Для того, чтобы старый код с all был кроссбраузерным применяют такую функцию:

<script>
function set_document_all() {
var elements = document.getElementsByTagName("*")
var i
for(i=0; i<elements.length; i++) {
var element = elements.item(i)
if(element.name) document.all[element.id] = element
}

for(i=0; i<elements.length; i++) {
var element = elements.item(i)
if(element.id) document.all[element.id] = element
}
}
</script>

Sign up to leave a comment.

Articles