Как я могу выяснить, какой узел узла вызывает асинхронные ошибки быстрее?

Question

Я столкнулся с проблемой при тестировании довольно большого рефакторинга (в этом случае при переносе старого сервиса из node.js от 0,12 до 10.x).Мы используем grunt, поэтому я получил следующие результаты из grunt nodeunit:all:

...
verify-api.routes.test.js
test setValues (pass)
Fatal error: Cannot read property 'setUp' of undefined

Некоторое прибегание к поиску приводит к нескольким потокам - этот - хороший синопсис, который правильно показывает эту ошибкуэто когда test.done вызывается несколько раз.

Отлично!Нет проблем.Вооружившись тем, что вы теперь копаетесь в verify-api.routes.test.js, где вы видите / предполагаете, что проблема определяется на основе результатов.Только - ты не прав.Оказывается, что ошибка (в моем случае) находится в двух наборах тестов до verify-api.routes.test.js среди полного набора выполненных тестов.Чтобы быть справедливым по отношению к узлу узла, это отчасти грубая ошибка, поскольку вывод вводит нас в заблуждение при определении verify-api.routes.test.js ... но, как показано внизу, другие способы просто проясняют, что узел узла не знает, где находится проблема - чтотолько незначительно лучше.

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

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

---

Как уже упоминалось, некоторые бегуны узловых узлов дают разные результаты... более / менее вводит в заблуждение в зависимости от контекста:

Я получил следующий вывод при непосредственном запуске nodeunit с использованием: nodeunit tests/**/*.test.js

OK: 162 assertions (2720ms)

FAILURES: Undone tests (or their setups/teardowns): 
- test setValues

И это с помощью IDEA Intellij, который приятно дает намнемного больше информации:

./node_modules/nodeunit/lib/core.js:285
    if (group.setUp) {
              ^
TypeError: Cannot read property 'setUp' of undefined
    at wrapGroup (./node_modules/nodeunit/lib/core.js:285:15)
    at Object.exports.runSuite (./node_modules/nodeunit/lib/core.js:93:13)

Answer 1

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

1.Непрерывная интеграция

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

2.Peer Review / Pair Coding

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

3.Использование async

Если вы занимаетесь асинхронным программированием, вам действительно стоит заглянуть в эту библиотеку, чтобы сохранить код немного чище.Async также имеет почти волшебные компоненты, которые могут управлять асинхронным управлением зависимостями, фильтрацией и многим другим.Если вы разрабатываете код узла, то получите (async) [https://github.com/caolan/async] сейчас.

---

Последнее, но не менее важное ... сегодня мне больше всего помогло выполнение тестов в изоляции с использованием find:

4.Запускайте тесты изолированно, используя find

. Сегодня мне больше всего помогло выполнение тестов изолированно, используя 'find'.До этого мы могли бы разделить тесты на группы, чтобы попытаться сузить пространство поиска - стиль двоичного поиска - до тех пор, пока мы не получим что-то работающее.

Я создал правило в скриптах пакетов, чтобы сделать это для меня - с некоторым отголоском, чтобы прояснить, какие выводы принадлежат к каким тестам:

"find-run-all-tests": "time find . -not -path \"./node_modules/*\" -type f -name \"*.test.js\" -exec echo \\n----------- Testing : {} --------------- \\; -exec node_modules/nodeunit/bin/nodeunit {} \\; -exec echo ----------- Finished : {} --------------- \\; ",

Это, конечно, позволяет нам npm run find-run-all-tests от проекта.Преимущества этого заключаются в том, что: а) он запускает версию узла узла, продиктованную проектом, б) показывает нам, сколько времени было потрачено на выполнение всего комплекта, и в) создает выходные данные, которые четко указывают на то, какой комплект был проблемой, и г) выполняет каждый тест.при полной изоляции перезапускающий узел каждый раз (большое снижение производительности здесь):

tokenoftrust-routes.test.js

✔ test login with basic privileges works.
✔ non-privileged access of privileged page. - when user is not logged in they should be directed to log-in
✖ non-privileged access of privileged page. - when user is logged in they should get an error page

FAILURES: Undone tests (or their setups/teardowns): 
- non-privileged access of privileged page. - when a non-test user is logged in they should STILL be able to see Developer Home

To fix this, make sure all tests call test.done()

----------- Testing : ./website/tests/apiKeysInvite-routes.test.js ---------------
----------- Testing : ./tests/services/requestService.test.js ---------------

requestService.test.js
✔ request service - expire request works.
✔ request service basic CRUD operations on objects work.
✔ request service basic CRUD operations on simple types.

OK: 15 assertions (834ms)
----------- Finished : ./tests/services/requestService.test.js ---------------

Опять же - я не вижу, чтобы мы выполняли это все время, до н.э. из-за снижения производительности.В нашем случае тесты выполнялись в 5 раз дольше, но при крохотной стоимости в 4 дополнительных минуты это помогло мне изолировать нас, изолировать ряд проблем в большом количестве тестовых наборов, чтобы мы могли пропустить некоторые контрпродуктивные исследования, которые мы обнаружили.делает.

---

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

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