Не стоит забывать и про работу сайта после загрузки jQuery, а он ни скоростью ни потреблением памяти похвастаться не может. Описанные проблемы с перформансом решает jBone, если конечно вы готовы пойти на менее богатый API.
Еще могу добавить, что после перевода приложения с jQuery на jBone сократили время загрузки сайта, процессинг и потребление памяти в среднем в 2 раза. Не уверен, что дело только лишь в jBone, так как по пути переписали еще не мало всего, но результат радует. Уже давно думаю о полноценной статье об этом.
Я считаю, что эти библиотеки полностью покрывают ваши потребности, новым людям на проекте будет проще читать их документацию, к тому же они имеют хороший задел в функциональности на будущее.
В общем, мне кажется это тот случай, когда велосипед — во зло.
Оче хорошо что вы написали его сами написали и поняли принцип работы фреймворков для тестирования изнутри, но не стоит призывать его использовать, вдруг кто то начнет :)
На сколько я понял, автор ставил другие задачи. Свагер создает UI для разработчиков, автор же предлагает решение, которое используют непосредсвтенно кастомеры (пользователи).
Было бы интересно) Толи и у PHP, то ли у Python такие оптимизации кстати есть. Но все JS тесты, который я писал или видел на jsperf, говорят об обратном.
Тест (Benchmark) не должен возвращать значение. В результате мы получаем информацию о том, сколько код внутри теста выполнялся, что именно этот код делает, нам знать не нужно. В итоге мы сравниваем время выполнения всех тестов внутри набора (Suite), и узнаем кто и на сколько быстрее.
Интересно, сами решаем подобную проблему. У вас не возникает трудностей с тем, что заранее не известно, какие именно элементы шаблона прийдется изменять в той или иной версии продукта, а на всех тегах расставлять «bl-» атрибуты может быть не удобно. Видите какие то пути решения этой проблемы с вашим подходом?
Библиотка не знает ничего о вашем коде, событие клика генерируется слчайным образом, с помощью объекта, полученного вызовом document.createEvent("MouseEvents"). Это значит, что эффект будет примерно тот же, что и от случайного клика (или dblclick, mousedown и т.д.) реальной мышью пользователя в какой либо участок экрана.
У себя решил эту проблему переопределением метода, который отвечает за переходы по страницам, и теперь в тестовом энвайроменте редирект в принципе не возможен. По умолчанию библиотека под это не заточена, и лог сбрасывается перед каждым запуском тестов (в вашем случае при переходам по страницам).
Как решение могу предложить переопределить объект логера, и сохранять лог например в localStorage, тогда при завершении тестов, сможете лог достать оттуда.
Второй вариант — запускать тесты в фантоме с помощью grunt-gremlins, где есть доступ к файловой системе. Сейчас логирования в файл еще нет, но появится в ближайшее время, так же в планах удобный менеджмент логирования для разных подзадач.
А вы не думали о том, чтобы просто написать новый сборщик для AMD проектов? Мне кажется, это было бы куда полезнее, так как тогда была бы возможность уже в готовых проектах использовать ваш сборщик.
Тогда могу только посоветовать сравнивать не html как есть, а какие то свойства/атрибуты в HTML, которые для вас критичны, в общем chai-jquery этим и занимается.
2. По поводу DOM, он у вас должен генерироваться одинаково во всех браузерах, если сгенерированный HTML разный, тесты должны падать, или вы имеете в виду что то другое?
3. jQuery объекты можно сравнивать с помощью deep equal, в chai это делается так:
expect($('h1')).to.be.deep.equal($('h1'));
Больше методов для тестирования jQuery в chai-jquery.
Еще могу добавить, что после перевода приложения с jQuery на jBone сократили время загрузки сайта, процессинг и потребление памяти в среднем в 2 раза. Не уверен, что дело только лишь в jBone, так как по пути переписали еще не мало всего, но результат радует. Уже давно думаю о полноценной статье об этом.
И да, против них самих я ничего не имею, всеми руками за.
Я считаю, что эти библиотеки полностью покрывают ваши потребности, новым людям на проекте будет проще читать их документацию, к тому же они имеют хороший задел в функциональности на будущее.
В общем, мне кажется это тот случай, когда велосипед — во зло.
Оче хорошо что вы написали его сами написали и поняли принцип работы фреймворков для тестирования изнутри, но не стоит призывать его использовать, вдруг кто то начнет :)
Картинка да, другая, если сбивает с толку, сейчас поменяю)
document.createEvent("MouseEvents")
. Это значит, что эффект будет примерно тот же, что и от случайного клика (или dblclick, mousedown и т.д.) реальной мышью пользователя в какой либо участок экрана.Вы можете сконфигурировать этого гремлина, указав в какую именно область экрана гремлин должен кликать (метод positionSelector), с какими именно элементами он может работать (canClick) и какие типы эвентов он должен генерировать (см. по умолчанию)
Как решение могу предложить переопределить объект логера, и сохранять лог например в localStorage, тогда при завершении тестов, сможете лог достать оттуда.
Второй вариант — запускать тесты в фантоме с помощью grunt-gremlins, где есть доступ к файловой системе. Сейчас логирования в файл еще нет, но появится в ближайшее время, так же в планах удобный менеджмент логирования для разных подзадач.
Извините, а чем она проще в использовании чем requirejs?
а в тестах подменить этот метод, например с помощью spy в sinon следющим образом:
2. По поводу DOM, он у вас должен генерироваться одинаково во всех браузерах, если сгенерированный HTML разный, тесты должны падать, или вы имеете в виду что то другое?
3. jQuery объекты можно сравнивать с помощью deep equal, в chai это делается так:
Больше методов для тестирования jQuery в chai-jquery.
Вот проект, который занимается практически тем же самым, и дела у него идут не лучшим образом.
А вообще удачи, надеюсь у вас получится лучше :)