Mocha: - вариант заказа для случайного порядка проверки?

да, довольно легко избежать перекрестных зависимостей без помощи инструментов

Хотя это просто to avoid cross-test dependencies without help of tooling , также легко добавить такую ​​зависимость в набор тестов, не заметив этого. Ошибка в наборе тестов обычно превращается в ошибку в тестируемой системе. Эти ошибки сложно отследить, поскольку код якобы тестируется.

Тестирование на отсутствие перекрестных зависимостей невозможно без инструментария.

@visionmedia ,

+1 @yanovich. Я бы использовал опцию случайного порядка, которая выводит начальное число. Это было бы очень полезно в среде CI.

@visionmedia , модели мангуста представляют собой простой пример зависимостей между тестами. mongoose.model 'User', UserSchema добавляет модель в массив mongoose.models . Таким образом, можно создать файл, который зависит от модели пользователя, загружаемой в mongoose.models. В качестве примера возьмем Comment.find().populate('_user').exec(cb) . Если пользовательский тест запускается перед тестом комментариев, он будет выполнен нормально, поскольку предположительно require('./models/user') (или что-то в этом роде) загрузил модель User в mongoose.models. Но если тест комментариев выполняется перед пользовательским тестом, вы получите эту ошибку Schema hasn't been registered for model "User" . Это могло произойти в производственной среде, когда api комментариев запускается перед пользовательским api, а файл комментариев не знал, что он имеет межфайловую зависимость.

Если тестовый файл содержит файл require ('./ models / user') (или что-то еще) и загружает пользователя в mongoose.models, возможно, что проблема в производстве по-прежнему не устранена. Однако случайный порядок был бы еще одним полезным инструментом для обнаружения подобных потенциальных проблем.

Надеюсь, это хорошо сформулировал. Жду ваших мыслей.

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

Спасибо, что подумали об этом.

Как и в большинстве случаев в коде, знающим людям легко избежать этого намеренно. Избежать этого непреднамеренно труднее. И если вы не знаете, что это даже проблема (например, команды со смешанным опытом), это вполне вероятно :)

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

+1 заинтересовано.

Было бы неплохо! Я обнаружил, что мои тесты не работают, переименовав имена файлов, тьфу.

+1 это важно

: +1:

: +1:

+1 Это довольно большой недостаток.

Семантика rspec довольно прочная: вы можете передать начальное значение порядка или выбрать его случайным образом. Если он выбирает семя наугад, он распечатывает его, поэтому его легко воспроизвести.

Часто не так просто избежать зависимостей между тестами. Иногда из-за непредвиденных глобальных взаимодействий, иногда из-за удобства. Я подозреваю, что более 50% проектов, использующих мокко, потерпят неудачу при тестировании, если порядок будет случайным. Вот пара примеров, которые, похоже, зависят от порядка выполнения теста:

https://github.com/visionmedia/mocha/blob/master/test/hook.async.js#L95
https://github.com/visionmedia/superagent/blob/master/test/node/not-modified.js#L31

Эти два набора тестов перечислены на сайте http://visionmedia.github.io/mocha/ как образцы, и я не тратил много времени на поиск проблем.

Я открою это заново. Думаю, это было бы полезно. Несмотря на то, что есть способы определить глубину перекрестного тестирования без инструментов, если мы сможем это автоматизировать, это сэкономит время людей.

Немного поигравшись с этим, это кажется нетривиальным из-за иерархической природы сюитов. Тесты запускаются путем рекурсии в Suite. Чтобы запускать _Tests_ случайным образом, нам нужно было бы их перечислить, рандомизировать, а затем работать в обратном направлении.

Это приведет к тому, что хуки before() и after() будут несколько бессмысленными, поскольку они будут выполняться _n_ раз за _n_ тесты в Suite (или, скорее, в _худшем_ случае, но только если мы будем осторожны ), поскольку мы постоянно меняем контекст. Похоже, это приведет к снижению производительности.

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

Конечно, я предполагаю, что то, что я здесь описал, - это то, о чем просят. Подобная функция требует спецификации.

Другие варианты включают «рандомизировать наборы» или «рандомизировать тесты в наборах» или их комбинацию. На практике это означает, что как только вы находитесь в describe() блоке _A_, вы не можете выполнять тесты в любом родительском или родственном describe() блоке _B_, пока не будут выполнены все тесты в _A_ (что выглядит гораздо более простой реализацией и не вызовет замешательства с before() / after() ).

Я (и я думаю, что другие) прошу о простейшем из вариантов:

• рандомизируйте тесты на самом низком уровне: в пределах одного блока описания; перемешайте "это" утверждения.
• рандомизировать порядок комплектов верхнего уровня (или рандомизировать порядок загружаемых файлов)

Я не думаю, что есть смысл перемешивать вещи на промежуточных уровнях.

Конечно взлом, но работает на самом низком уровне https://github.com/syrnick/mocha/compare/random_order?expand=1&w=0

mocha - fail
connect - pass
superagent - fail
express - pass** 
websocket.io - pass (can't tell for sure)

** Я получил 2 периодических сбоя из 100 запусков всего набора тестов в любом случае.

Хорошо, это, безусловно, легче реализовать!

Я искал для этого библиотеку seedrandom ; используйте опцию pass .

Приму пиар.

Скорее всего, я очищу этот код и скорректирую набор тестов в течение следующих нескольких дней. Является ли подчеркивание слишком сильной зависимостью для этого? Скорее всего, я мог бы использовать что-то вроде этого: http://stackoverflow.com/questions/6274339/how-can-i-shuffle-an-array-in-javascript.

@boneskull Я поддерживаю ваше решение открыть это заново. : +1:

Другие варианты включают «рандомизировать наборы» или «рандомизировать тесты в наборах» или их комбинацию.

Мне кажется, более чем достаточно. Нет необходимости возвращаться, перечислять и перемешивать.

Приятно слышать, что это происходит.

Интересно, обработал ли rspec рекурсивное перемешивание? Может быть стоит посмотреть
в их коде?

Во вторник, 26 августа 2014 г., Джошуа Аппельман [email protected]
написал:

@boneskull https://github.com/boneskull Я поддерживаю ваше решение
открыть это заново. [изображение:: +1:]

Другие варианты включают «рандомизировать наборы» или «рандомизировать тесты в
Suites »или их комбинация.

Мне кажется, более чем достаточно. Не нужно возвращаться полностью вниз,
перечислить и перемешать.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/visionmedia/mocha/issues/902#issuecomment -53482124.

@syrnick Я бы не стал принимать PR с такой большой зависимостью и вместо этого использовал бы seedrandom . Без него я не уверен, как вы собираетесь поддерживать посев. seedrandom позволяет указать семя или нет, и если вы этого не сделаете, она вернет вам семя. Затем мы могли бы отобразить его пользователю и позволить ему указать его, как RSpec.

@syrnick Имейте в виду, что если вы действительно генерируете семена, они не могут быть «отображены» без передачи их репортерам. Я не очень хорошо знаком с архитектурой отчетности, поэтому не могу сказать вам наверняка, или что делать ...

+1

Я не смотрел на реализацию, но +1 к случайному выполнению теста по умолчанию очень важен.

@syrnick Пожалуйста, дайте мне знать, если вы собираетесь это сделать, спасибо.

Я счастлив сделать это, но у меня нет немедленного расчетного времени прибытия.

: +1:, вам все еще нужна помощь с пиаром?

Действительно, похоже, что никто не начал над этим работать.

Во-первых, похоже, что перетасовка Фишера-Йейтса здесь подойдет.

Во-вторых, я бы предпочел иметь --order random , --order random-suites и --order default в качестве трех аргументов с необязательным :<seed> .

+1. Только что обнаружил ошибку, которая обнаружилась бы давным-давно, если бы тесты были рандомизированы. Подобно тому, как это поддерживает RSpec.

Вот код, который демонстрирует полезность случайного упорядочивания тестов. Хотя есть и более простые примеры, я только что столкнулся с этим во время демонстрации TDD. Если вы поменяете порядок тестов на обратную, первый тест всегда не пройден.

game.js:

var express = require('express');
app = exports.app = express();

var sum = 0;

app.post('/bowl/:pins', function(req,res) {
    var score = parseInt(req.params.pins);
    console.log('Bowled ' + score);
    sum += parseInt(req.params.pins);
});

app.get('/score', function(req,res) {
    console.log('Sum: ' + sum);
    res.send(sum + '');
});

app.listen(process.env.PORT || 3000);

test \ gameTest.js:

var request = require('supertest'),
    should = require('should'),
    game = require('../game.js').app;

describe('a game of bowling', function() {
    describe('a gutter game', function() {
        it('should score 0', function(done){
            request(game).get('/score').expect(200, '0', done);
        });
    });

    describe('a single pin game', function() {
        it('should score 20', function(done){
            for(var i = 0; i < 20; i++) {
                request(game).post('/bowl/1').expect(200, done);
            }
            request(game).get('/score').expect(200, '20', done); 
        });
    });
});

Я бы хотел это получить.

: +1:

Как только вы задействуете несколько глобальных переменных (это Javascript, помните), начнете заглушать серверные вызовы и вставлять / удалять вещи из DOM в ваших тестах, становится очень легко добавить зависимость от порядка. Рандомизация порядка тестирования поможет обнаружить это раньше, чем позже.
: +1:

: +1:

: +1:

+1

Случайный порядок по умолчанию с необязательным начальным значением для воссоздания порядка было бы отличной функцией.

+1, мои тесты иногда терпят неудачу при запуске в случайном порядке ...

А пока на помощь приходит unix (к сожалению, random seed не поддерживается):

mocha `ls -1 test/*.js | sort --random-sort `

Погуглил, в каком порядке мокко запускает тесты, и нашел это. Каков порядок выполнения по умолчанию при отсутствии рандомизации? Всегда ли это порядок, в котором тесты физически появляются в файле?

: +1:

@danielabar да, они будут в том порядке, в котором они появляются в файле.

@NicolasJacob ну, случайное семя на самом деле в некоторой степени возможно, кстати. :)

$ seq 10 | shuf --random-source=<(yes 2883)
1
7
3
4
6
2
10
5
9
8

https://github.com/bahmutov/rocha работает для этого.

@boneskull, хотя это старая проблема, метка PR Please еще действительна? Если да, то я получу что-нибудь в ближайшее время.

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

Могу я предложить просто использовать https://github.com/bahmutov/rocha, если он работает?

Потрясающий соус

Что вы имеете в виду под подключаемым интерфейсом? Можно ли через этот интерфейс ввести рандомизированный порядок тестирования?

+1 за запрос функции

@sulabhjain , предыдущие и следующие сторонники, пожалуйста, используйте реакцию +1.

Прогресс в этой ветке .

+1 за эту функцию

Это действительно одна из наиболее важных функций для среды тестирования, которая помогает поддерживать независимость тестов. Эта базовая функция есть в каждой основной тестовой среде JVM.

+1 за эту функцию. Да, легко избежать тестовых зависимостей при достаточном опыте и / или работе в одиночку, но это не всегда так.

Для тех, кто заинтересован в этой функции, они могут отправить PR для ветки рандомизации, чтобы помочь закончить то, что осталось.

+1 за эту функцию. Очень признателен за то, что для этого существует ветка.

Все еще жду этого :))

Это может быть действительно полезно.
@tj Я понимаю, что легко избежать тестовых зависимостей, когда вы работаете с людьми, обладающими некоторыми базовыми навыками тестирования, но иногда вам нужно взять на себя команду разработчиков, и вы можете столкнуться с людьми, не имеющими даже базовых знаний о тестовых примерах.

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

@boneskull Отличная работа! Каков статус этого исправления? Вам в чем-нибудь нужна помощь?

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

mocha $(find tests/ -name *.spec.js | shuf)

К сожалению, это не перемешивает тестовые примеры в одном и том же примере, но это все равно довольно умно и удобно!

+1 в поддержку этой функции

Это все еще на столе, но требует внимания со стороны не-меня

Итак, что на самом деле здесь осталось? С чего начать?

Хотелось бы увидеть это реализованным ❤️

Я только что нашел пакет choma , который предоставляет очень простой плагин для Mocha для рандомизации порядка наборов тестов и кейсов. Хорошая альтернатива роче, о которой говорилось ранее. Просто и решает проблему для меня!

Альтернативой может быть параллельное выполнение тестов:

• Карма (+ мокко или жасмин) - параллельная карма - в данный момент не поддерживает покрытие кода
• Мокко - мокко-параллельные тесты или mocha.parallel
• Jest - делает это по умолчанию