Да, одна из причин в нашем случае это именно legacy: у нас большой объем кода где-то 15-летней выдержки. В свое время решили зафиксировать его поведение юнит-тестами, чтобы разработчики, исправляя баг, не вносили новые.
Это суть Sinon fake timers — они подменяют стандартные реализации setTimeout и setInterval, но взамен дают контроль за их исполнением. С другой стороны в тестах должно соблюдаться правило: испортил глобальный объект для теста — верни на место. Иначе последствия будут непредсказуемы.
Какой вариант вы предлагаете? Как правильно локализовать ошибку в указанном примере?
В принципе идея получить больше контроля над асинхронным flow заманчива. Мы даже сделали что-то подобное для получения бОльшего количества информации в серверных логах: наш фреймворк изоморфен и работает в т.ч. на сервере, собранным в виде надстройки над V8. Там развитая система логирования, в коллстеках можно отслеживать контекст вызова некоторых других асинхронных операций.
Но не менее часто вставка setTimeout является костылем ad hoc, но реальность такова, что другого варианта у разработчика перед дедлайном просто нет. А потом оказывается, что у него из-за изменения кода еще и юнит-тест упал, надо исправлять. Это все плохо, в итоге копится технический долг, который надо как-то отдавать… но это уже тема отдельного разговора. Тут же я рассматриваю ситацию, как с этим жить.
Простите. Но с другой стороны язык впитывает иностранные термины, и те же «браузер» или «фрейморк» уже не кажутся чем-то инородным. Найти границу бывает сложно, иногда в подобных текстах предложения превращаются в череду русских и английских слов, что тоже не очень. Но я учту, спасибо.
Посмотрел на Jest. Сразу бросаются параллельный запуск тестов и поддержка coverage — это интересно.
По сути обсуждения:
— Работа а асинхронным кодом построена по той же схеме, что и в Мокка: либо через callback, либо через Promise, тут отличий нет.
— Работа с setTimeout реализована аналогично четвертому рассмотренному в статье решению (Sinon fake timers). Плюс в примерах рассматривается ситуация посложнее — с вложенными друг в друга вызовами setTimeout. И это приятно: чувствуется, что люди разгребали похожие проблемы.
В целом — заслуживающий внимания тестовый фрейморк, многие вещи доступны из «коробки», в то время как в нашем случае мы используем сторонние решения. Плюс в доке освещены интересные паттерны тестов.
Спасибо за наводку, мы к Мокке пришли давно, может уже стоить рассмотреть альтернативы.
Какой вариант вы предлагаете? Как правильно локализовать ошибку в указанном примере?
Насколько я понял zone.js не стандартизован?
Часто это последствия каких-то оптимизаций или используемых подходов.
Но не менее часто вставка setTimeout является
костылемad hoc, но реальность такова, что другого варианта у разработчика перед дедлайном просто нет. А потом оказывается, что у него из-за изменения кода еще и юнит-тест упал, надо исправлять. Это все плохо, в итоге копится технический долг, который надо как-то отдавать… но это уже тема отдельного разговора. Тут же я рассматриваю ситацию, как с этим жить.По сути обсуждения:
— Работа а асинхронным кодом построена по той же схеме, что и в Мокка: либо через callback, либо через Promise, тут отличий нет.
— Работа с setTimeout реализована аналогично четвертому рассмотренному в статье решению (Sinon fake timers). Плюс в примерах рассматривается ситуация посложнее — с вложенными друг в друга вызовами setTimeout. И это приятно: чувствуется, что люди разгребали похожие проблемы.
В целом — заслуживающий внимания тестовый фрейморк, многие вещи доступны из «коробки», в то время как в нашем случае мы используем сторонние решения. Плюс в доке освещены интересные паттерны тестов.
Спасибо за наводку, мы к Мокке пришли давно, может уже стоить рассмотреть альтернативы.