Обсуждений тред

[monolithed]

http://jasmine.github.io/

Mocha или QUnit в разы удобней. ИМХО

[Shaci]

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

там самое "сложное" - шпионы для тестирования ajax вызовов(опять же я так думаю), есть блог loftblog , там есть видео про тестирование http://loftblog.ru/tag/jasmine/

хотя проще наверное доки прочитать

[kobezzza]

QUnit

Я пересел с qUnit как раз, т.к. когда тестов стало больше 100, то их поддержка стало проблемной, а в Jasmine удобная неограниченная система разделов и на мой взгляд очень приятный BDD синтаксис. Сейчас общее количество тестов на проекте у меня примерно 3к на Jasmine и пока всё хорошо.

С Mocha не работал, но когда прочитал, что там нужно ещё отдельно assert движок подключать, то выбрал Jasmine, т.к. там всё из коробки.

[kobezzza]

там самое "сложное" - шпионы для тестирования ajax вызовов(опять же я так думаю), есть блог loftblog , там есть видео про тестирование http://loftblog.ru/tag/jasmine/

хотя проще наверное доки прочитать

Писать асинхронные тесты очень просто:

it('тесты', function (done) {
    setTimeout(function () {
        expect(true).toBeTruthy();
        done();
    }, 500);
});

[l-liava-l]

kobezzza,
а там можно сделать так. что вот я написал тест для участка кода, и указал что ожидаю в таком то месте такой то тип переменной. И если вдруг в этом месте оно не такое мне алертовала консоль? А потом я мог например просмотреть все этапы изменения этой переменной в разных блоках кода и выявить где допустил ошибку

[kobezzza]

kobezzza,
а там можно сделать так. что вот я написал тест для участка кода, и указал что ожидаю в таком то месте такой то тип переменной. И если вдруг в этом месте оно не такое мне алертовала консоль? А потом я мог например просмотреть все этапы изменения этой переменной в разных блоках кода и выявить где допустил ошибку

Unit-тесты работают с интерфейсом, т.е. если ты реализуешь какой то способ в API своей функции, то конечно же его можно слушать, а просто сказать, мол сделай брекпоинт на 21 строке и посмотри что там - конечно нельзя, а если бы было можно, то не нужно так делать

[monolithed]

Я пересел с qUnit как раз, т.к. когда тестов стало больше 100, то их поддержка стало проблемной, а в Jasmine удобная неограниченная система разделов

Не помню таких проблем в Mocha или QUnit (modules).

Единственное чего и правда нет, так это вложенных кейсов
Что касается ассертов, то мне они нафиг не нужны, я не планирую писать true.should.be.ok. Собственно этим мне и не нравится Jasmine.

PS: положа руку на седце, мне не нравится не один из существующих фреймворков для тестирования. Но свой мне так и не удалось допилить до желаемого уровня.

[l-liava-l]

Unit-тесты работают с интерфейсом, т.е. если ты реализуешь какой то способ в API своей функции, то конечно же его можно слушать, а просто сказать, мол сделай брекпоинт на 21 строке и посмотри что там - конечно нельзя, а если бы было можно, то не нужно так делать

Тоесть я скармливаю тесту модуль со своей апихой, и он просто пробегается по ней и смотрит соответсвуют ли ожидания действительности? даже без сверхестественного обошлось что ли

Теперь передо мной стоит задача, че из всех либ для тестирования выбрать, но читаю про jasmine, там видно будет

[kobezzza]

или QUnit (modules).

Может я что путаю, но там ведь нельзя делать:

module('1', function () {
    module('1.1', function () {
        module('1.1.1', function () {
             // и т.д.
        });
    });
});

Да и в любом случае мне нравится подход к синтаксису в Jasmine.

Собственно этим мне и не нравится Jasmine

Наш спор из серии: табы или пробелы

l-liava-l, если абстрагироваться совсем то схема такая: ты делаешь вызов своей функции и результат сравниваешь с ожидаемым, и если он не такой, то валится алерт.

[l-liava-l]

l-liava-l, если абстрагироваться совсем то схема такая: ты делаешь вызов своей функции и результат сравниваешь с ожидаемым, и если он не такой, то валится алерт.

Да я пральна понял)
kobezzza,
Спасибо!)