Pull to refresh
21
0
Alexey Kupriyanenko @Upward

User

Send message
Не стоит забывать и про работу сайта после загрузки jQuery, а он ни скоростью ни потреблением памяти похвастаться не может. Описанные проблемы с перформансом решает jBone, если конечно вы готовы пойти на менее богатый API.

Еще могу добавить, что после перевода приложения с jQuery на jBone сократили время загрузки сайта, процессинг и потребление памяти в среднем в 2 раза. Не уверен, что дело только лишь в jBone, так как по пути переписали еще не мало всего, но результат радует. Уже давно думаю о полноценной статье об этом.
Мне кажется, вас спасали не промисы, а то, что вы вовремя написали единый интерфес через который общались с сервером ;)

И да, против них самих я ничего не имею, всеми руками за.
mocha+chai/jasmine = успех;

Я считаю, что эти библиотеки полностью покрывают ваши потребности, новым людям на проекте будет проще читать их документацию, к тому же они имеют хороший задел в функциональности на будущее.

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

Оче хорошо что вы написали его сами написали и поняли принцип работы фреймворков для тестирования изнутри, но не стоит призывать его использовать, вдруг кто то начнет :)

Спасибо, выглядит интересно, к сожалению завязано на инфраструктуру кармы.
На сколько я понял, автор ставил другие задачи. Свагер создает UI для разработчиков, автор же предлагает решение, которое используют непосредсвтенно кастомеры (пользователи).
Было бы интересно) Толи и у PHP, то ли у Python такие оптимизации кстати есть. Но все JS тесты, который я писал или видел на jsperf, говорят об обратном.
Тест (Benchmark) не должен возвращать значение. В результате мы получаем информацию о том, сколько код внутри теста выполнялся, что именно этот код делает, нам знать не нужно. В итоге мы сравниваем время выполнения всех тестов внутри набора (Suite), и узнаем кто и на сколько быстрее.
Да, обертка в планах, думаю будет полезно для прогона тестов в рамках CI.

Картинка да, другая, если сбивает с толку, сейчас поменяю)
Интересно, сами решаем подобную проблему. У вас не возникает трудностей с тем, что заранее не известно, какие именно элементы шаблона прийдется изменять в той или иной версии продукта, а на всех тегах расставлять «bl-» атрибуты может быть не удобно. Видите какие то пути решения этой проблемы с вашим подходом?
Не хотите вместо своей балалайки, посмотреть в сторону jBone?)
Спасисбо, интересно.
Какие тулзы, они опенсорсные? Потому что без них не имеет смысла использовать modules в продакшене, так как большого желания писать самому нет.
Библиотка не знает ничего о вашем коде, событие клика генерируется слчайным образом, с помощью объекта, полученного вызовом document.createEvent("MouseEvents"). Это значит, что эффект будет примерно тот же, что и от случайного клика (или dblclick, mousedown и т.д.) реальной мышью пользователя в какой либо участок экрана.

Вы можете сконфигурировать этого гремлина, указав в какую именно область экрана гремлин должен кликать (метод positionSelector), с какими именно элементами он может работать (canClick) и какие типы эвентов он должен генерировать (см. по умолчанию)
У себя решил эту проблему переопределением метода, который отвечает за переходы по страницам, и теперь в тестовом энвайроменте редирект в принципе не возможен. По умолчанию библиотека под это не заточена, и лог сбрасывается перед каждым запуском тестов (в вашем случае при переходам по страницам).

Как решение могу предложить переопределить объект логера, и сохранять лог например в localStorage, тогда при завершении тестов, сможете лог достать оттуда.

Второй вариант — запускать тесты в фантоме с помощью grunt-gremlins, где есть доступ к файловой системе. Сейчас логирования в файл еще нет, но появится в ближайшее время, так же в планах удобный менеджмент логирования для разных подзадач.
Главное, чтобы эти гремлины не захватили ваше приложение.
А вы не думали о том, чтобы просто написать новый сборщик для AMD проектов? Мне кажется, это было бы куда полезнее, так как тогда была бы возможность уже в готовых проектах использовать ваш сборщик.
Самая простая модульная система

Извините, а чем она проще в использовании чем requirejs?
Тогда могу только посоветовать сравнивать не html как есть, а какие то свойства/атрибуты в HTML, которые для вас критичны, в общем chai-jquery этим и занимается.
1. В случае с API браузера, лучше написать метод, который будет выполнять необходимые вам действия:

namespace.util = {
    redirect: function(url) {
         window.location = url;
    }
}

а в тестах подменить этот метод, например с помощью spy в sinon следющим образом:

sinon.spy(utils, "redirect");
//...
expect(namespace.util.redirect).have.been.calledOnce;
namespace.util.redirect.restore();

2. По поводу DOM, он у вас должен генерироваться одинаково во всех браузерах, если сгенерированный HTML разный, тесты должны падать, или вы имеете в виду что то другое?

3. jQuery объекты можно сравнивать с помощью deep equal, в chai это делается так:

expect($('h1')).to.be.deep.equal($('h1'));

Больше методов для тестирования jQuery в chai-jquery.
Ничего не было найдено!

Вот проект, который занимается практически тем же самым, и дела у него идут не лучшим образом.

А вообще удачи, надеюсь у вас получится лучше :)

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Registered
Activity