Комментарии 17
Это безумие. И код, и тесты.
+2
А можно поконкретнее про клиническу картину безумства? Примеру максимально упрощены, чтобы отразить суть проблемы.
0
При использовании такого подхода не забывайте восстанавливать все "как было" через вызов clock.restore(), иначе рискуете испортить тесты соседа.
Тест должен максимально локализовывать ошибку. А при таком подходе ошибку будут искать там, где её нет.
0
Это суть Sinon fake timers — они подменяют стандартные реализации setTimeout и setInterval, но взамен дают контроль за их исполнением. С другой стороны в тестах должно соблюдаться правило: испортил глобальный объект для теста — верни на место. Иначе последствия будут непредсказуемы.
Какой вариант вы предлагаете? Как правильно локализовать ошибку в указанном примере?
Какой вариант вы предлагаете? Как правильно локализовать ошибку в указанном примере?
0
используйте jest, он предоставляет манипуляции с таймерами
0
Посмотрел на Jest. Сразу бросаются параллельный запуск тестов и поддержка coverage — это интересно.
По сути обсуждения:
— Работа а асинхронным кодом построена по той же схеме, что и в Мокка: либо через callback, либо через Promise, тут отличий нет.
— Работа с setTimeout реализована аналогично четвертому рассмотренному в статье решению (Sinon fake timers). Плюс в примерах рассматривается ситуация посложнее — с вложенными друг в друга вызовами setTimeout. И это приятно: чувствуется, что люди разгребали похожие проблемы.
В целом — заслуживающий внимания тестовый фрейморк, многие вещи доступны из «коробки», в то время как в нашем случае мы используем сторонние решения. Плюс в доке освещены интересные паттерны тестов.
Спасибо за наводку, мы к Мокке пришли давно, может уже стоить рассмотреть альтернативы.
По сути обсуждения:
— Работа а асинхронным кодом построена по той же схеме, что и в Мокка: либо через callback, либо через Promise, тут отличий нет.
— Работа с setTimeout реализована аналогично четвертому рассмотренному в статье решению (Sinon fake timers). Плюс в примерах рассматривается ситуация посложнее — с вложенными друг в друга вызовами setTimeout. И это приятно: чувствуется, что люди разгребали похожие проблемы.
В целом — заслуживающий внимания тестовый фрейморк, многие вещи доступны из «коробки», в то время как в нашем случае мы используем сторонние решения. Плюс в доке освещены интересные паттерны тестов.
Спасибо за наводку, мы к Мокке пришли давно, может уже стоить рассмотреть альтернативы.
0
Когда уже Вы перестанете переводить термины?! Мокка, промизы…
Остановитесь, пока не поздно.
0
Насколько бредовой является идея абстрагировать тесты от любой асинхронщины с помощью zone.js? Может у кого-нибудь есть опыт интеграции, за пределами Angular.
+1
В принципе идея получить больше контроля над асинхронным flow заманчива. Мы даже сделали что-то подобное для получения бОльшего количества информации в серверных логах: наш фреймворк изоморфен и работает в т.ч. на сервере, собранным в виде надстройки над V8. Там развитая система логирования, в коллстеках можно отслеживать контекст вызова некоторых других асинхронных операций.
Насколько я понял zone.js не стандартизован?
Насколько я понял zone.js не стандартизован?
0
Zone.js несколько лет используется в Angular, в том числе и в тестах. Например, хелпер fakeAsync angular.io/api/core/testing/fakeAsync даёт возможность выполнить тест практически любого асинхронного кода синхронно.
Про стандартизацию мне ни чего не известно. А зачем?
Про стандартизацию мне ни чего не известно. А зачем?
0
Зачем вообще setTimeout в UI? Разве что setTimeout 0 для разрыва контекста, и то это на самом деле нужно очень редко.
0
Реальность жизни в асинхронном мире, использоваться может случайно либо намеренно.
Часто это последствия каких-то оптимизаций или используемых подходов.
Но не менее часто вставка setTimeout являетсякостылем ad hoc, но реальность такова, что другого варианта у разработчика перед дедлайном просто нет. А потом оказывается, что у него из-за изменения кода еще и юнит-тест упал, надо исправлять. Это все плохо, в итоге копится технический долг, который надо как-то отдавать… но это уже тема отдельного разговора. Тут же я рассматриваю ситацию, как с этим жить.
Часто это последствия каких-то оптимизаций или используемых подходов.
Но не менее часто вставка setTimeout является
0
Но если это ad hoc то вы получается делаете фреймворк для костылей.
Не поймите неправильно, технически подход к проблеме верный, но я думаю что если пишутся setTimeout то это систематическая ошибка и должна решаться обучением/написанием фреймворка убирающего потребность в setTimeout.
Тут ниже про анимации вспоминали, если приложить усилий то можно условно надёжно(целевым был только хром, в лисе тоже работает остальное не тестировалось) не только систематизировать подход к анимациям, но и за счёт обработки событий анимаций полностью избавиться от таймаутов как в коде приложения, так и в коде тестов. Мне кажется это более правильный подход, что конечно не отменяет поддержку легаси и решение проблем «уже есть 100500 setTimeout везде»
Не поймите неправильно, технически подход к проблеме верный, но я думаю что если пишутся setTimeout то это систематическая ошибка и должна решаться обучением/написанием фреймворка убирающего потребность в setTimeout.
Тут ниже про анимации вспоминали, если приложить усилий то можно условно надёжно(целевым был только хром, в лисе тоже работает остальное не тестировалось) не только систематизировать подход к анимациям, но и за счёт обработки событий анимаций полностью избавиться от таймаутов как в коде приложения, так и в коде тестов. Мне кажется это более правильный подход, что конечно не отменяет поддержку легаси и решение проблем «уже есть 100500 setTimeout везде»
0
Например таймеры часто используются в анимациях, обработке последовательностей событий и тому подобных вещах, которые завязаны на время.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как тестировать код, содержащий setTimeout/setInterval под капотом