Прочитал серию из двух хороших статей "Disguise-Driven Testing: Jest Mocks in Depth" Джо Моргана про использование моков в Jest.

Jest — это фреймворк для тестирования, разработанный Facebook, который развивался в самом начале как форк Jasmine. В первой части рассказывается про основы использования моков, зачем они нужны и как их использовать. Очень подробно разбирается пример их использования для подмены результатов вызова Rest API сервиса. Первая часть написана очень доступно, поэтому особенно рекомендую почитать её новичкам и тем, у кого небольшой опыт работы с инструментами для тестирования.

Во второй части статьи рассматриваются, на мой взгляд, более интересные примеры. Пример мока генератора уникального id, с возможностью его тонкой настройки. И пример мока библиотеки, которая работает с DOM API. В последнем примере тестируется React-компонент, использующий хуки. Для того чтобы useEffects заработал корректно, использовался небольшой трюк с задержкой с помощью async/await. Вторую часть статьи рекомендую тем, у кого уже есть опыт использования Jest. Скорее всего из неё вы узнаете что-нибудь новое.

#jest #mocks #testing

https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth
https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth-part-2

Прочитал интересную статью Алексея Круглова "Continuous integration в Яндексе".

В статье рассказывается о том, как происходит работа над проектами в Яндексе. Есть единый монорепозиторий. В нём содержится очень много кода (25Гб), над которым работают более 2000 разработчиков. Использование монорепозитория позволяет снизить издержки на систему CI/CD, предотвращает вероятность появления библиотек с похожей функциональностью (так как всё на виду) и снижает порог для внесения исправлений в смежные проекты (используется общий стек для работы с кодом).

На каждый коммит запускается прогон тестов. Запускаются только те тесты, которые необходимы. Чтобы обнаружить нестабильно работающие тесты, они прогоняются два раза. Если какие-то тесты начинают "моргать", то владельцы этих тестов начинают получать уведомления с проблемой. Также используются diff-тесты, которые могут однозначно определить проблемный коммит, который вызвал поломку тестов.

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

#ci #testing #yandex

https://habr.com/ru/company/yandex/blog/428972/

Кристоф Гуттандин рассказал про то, как он тестирует свою библиотеку на утечки памяти с помощью Puppeteer — "Automatically detect memory leaks with Puppeteer".

Для получения информации о потребляемой памяти в Puppeteer можно использовать метод metrics(). Кристофу этот способ не подошёл. Проблема в том, что для получения воспроизводимых результатов, надо перед запуском теста вызывать сборку мусора, что не всегда получается сделать. Плюс, когда начинает работать оптимизатор v8, потребляемая память может непредсказуемо измениться и тесты будут моргать.

В итоге, автор остановился на варианте с queryObjects(). С помощью него можно подсчитать количество всех объектов в heap, у которых в цепочке прототипов, содержится переданный в качестве аргумента объект (`queryObjects()` также доступен из консоли chrome dev tools).

На ум пришёл ещё такой способ использования queryObjects(). Если есть подозрение, что текут объекты с определённым прототипом, запрашиваем количество объектов с помощью queryObjects() в консоли браузера до и после проблемного кода и сравниваем. В общем, статья полезная. Советую почитать.

#testing #internals #puppeteer

https://media-codings.com/articles/automatically-detect-memory-leaks-with-puppeteer

Ричард Кроули из Slack рассказал про то, как они тестируют устойчивость сервисов к ошибкам — "Disasterpiece Theater: Slack’s process for approachable Chaos Engineering".

Для тестирования fault-tolerance команда Slack следует процессу, который они назвали "театром маленьких разрушений". В самом начале этого "представления" определяется, какая часть системы будет тестироваться, составляется план отключения и восстановления. Документируются гипотезы того, как будет себя вести поломанная система. Вот пример из статьи: "Отключение мастера MySQL приведёт к повышению времени ответа на 20 секунд для запросов, которые зависят от этой базы, для других запросов повышения таймингов не будет, ожидается менее 1000 неудачных запросов, которые будут заретраены клиентами”. Затем провоцируется поломка в тестинге. Гипотезы сверяются с тем, что произошло в реальности и делаются выводы. Если в тестинге, всё прошло хорошо, поломка провоцируется в проде. В статье есть пара примеров того, какие проблемы были обнаружены благодаря такому подходу.

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

https://slack.engineering/disasterpiece-theater-slacks-process-for-approachable-chaos-engineering-3434422afb54

#devops #backend #testing

Дэвид Петер из Mailchimp написал статью про то, каких подходов при тестировании придерживается их команда — "Designing automated tests for React".

В статье очень много дельных мыслей, к которым стоит прислушаться. Например, следует придерживаться баланса при написании тестов — огромное количество тестов само по себе может стать проблемой, так как тесты это код, который следует поддерживать и писать. Зачастую на написание тестов может уходить больше времени, чем на написание фичи. Но при этом было бы глупо совсем отказываться от тестов, поэтому надо хорошо взвешивать, что тестить, а что оставить в покое. Ещё из статьи запомнилось то, что html создавался без учёта динамичных пользовательских интерфейсов. ARIA-атрибуты позволяют выражать недостающую семантику для элементов страницы, и этим фактом следует пользоваться при написании тестов.

Единственное, что у меня вызвало вопросы — отказ от снепшот-тестирования. Автор пишет, что снепшоты не выражают намерений. Я считаю, что их интент состоит в том, что они закрепляют контракт на уровне того, какую вёрстку должен генерировать компонент (мини-аналог скриншот-тестирования). Но при этом их стоит использовать благоразумно (например, не более одного снепшот-теста на компонент), так как большое количество снепшотов сложно ревьювить, и на них просто могут перестать обращать внимание.

Как бы то ни было, статья отличная. Советую прочитать всем без исключения, даже если вы не используете React.

#testing #react

https://increment.com/testing/designing-automated-tests-for-react/

Николас Гаутей опубликовал статью про использование WebPageTest с SPA-приложениями — "Recipes for Performance Testing Single Page Applications in WebPageTest".

При прогоне тестов на производительность у SPA-приложений недостаточно замерять обычную загрузку страницы, так как страница динамически меняет своё состояние в зависимости от пользовательского ввода. Ситуация усугубляется ещё тем, что при использовании React и Redux, нельзя просто менять элементы ввода с помощью innerText на уровне DOM API, так как при таком изменении текста не будет меняться состояние стора.

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

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

#performance #testing

https://css-tricks.com/recipes-for-performance-testing-single-page-applications-in-webpagetest/

Глеб Бахмутов рассказал про визуальное тестирование с помощью Cypress — "Visual testing for React components using open source tools".

В качестве примера в статье была взята игра судоку, написанная на React. Для тестирования компонентов использовалась библиотека cypress-react-unit-test. Для визуального тестирования (сравнения скриншотов компонентов) — cypress-image-snapshot.

В статье есть примеры использования Cypress для мока модулей и таймеров. Есть очень подробный пример настройки визуального тестирования. Из-за особенностей рендеринга скриншоты одного и того же компонента будут разными в зависимости от версии браузера и операционной системы. Чтобы обойти эту проблему можно настроить процент, на который разрешено отличаться сравниваемым изображениям. Это хороший подход, но потенциально он может пропускать дефекты. Для надёжной генерации скриншотов в статье разбирается способ с использованием docker. В нём для генерации скриншотов используется точно такой же контейнер, какой работает в CI-системе.

Советую заглянуть в статью, если планируете добавить в свой React-проект визуальное тестирование.

#react #testing

https://glebbahmutov.com/blog/open-source-visual-testing-of-components/

Артём Захарченко рассказал про свой подход использования моков при тестировании кода — "When should I (not) use mocks in testing?".

В статье есть примеры хорошего и плохого использования моков. Разбирается вопрос использования моков на разных уровнях тестирования: в юнит-тестах, в интеграционных тестах, в E2E-тестах.

Самое главная идея статьи — не используйте моки, если без них можно обойтись. Иногда они могут быть полезны, например, при работе со временем, датами, внешними сервисами. Но в то же время не следует ими злоупотреблять, так как они могут замаскировать проблемы, которые могут возникнуть в проде.

Хорошая статья. Рекомендую почитать всем.

#testing

https://dev.to/kettanaito/when-should-i-not-use-mocks-in-testing-544e

Варун Вачнар пообщался с разработчиками из Adobe, BBC, Twilio, Shopify, Peloton и обобщил подходы, которые они используют при тестировании UI — "How to actually test UIs".

В статье рассказывается о подходах тестирования интерфейсов, создаваемых с помощью компонентного подхода. Для обособленного тестирования компонентов команды используют Storybook, для тестирования поведения компонентов — Testing Library, для тестирования доступности — Axe, для E2E-тестов — Playwright и Cypress.

Есть раздел про визуальное тестирование (тестирование скриншотами), но там нет упоминания инструментов с открытым исходным кодом, например, Hermione, Gemini, cypress-image-snapshot.

Как бы то ни было, статья хорошая. Очень рекомендую почитать.

#testing #tool

https://storybook.js.org/blog/how-to-actually-test-uis/

Недавно вышла новая версия Jest. Тим Секингер рассказал о новинках релиза — “Jest 27: New Defaults for Jest, 2021 edition”.

— В интерактивном режиме появилась возможность поочерёдного перехода по упавшим тестам.
— Инлайн-снапшоты теперь можно использовать без подключения Prettier.
— Инициализация тестов была ускорена на 70%.
— Продолжается работа над внедрением ESM. Её поддержка уже есть в кастомных раннерах, репортерах и watch-плагинах.
— Добавлена асинхронная поддержка transform для эффективной транспиляции с помощью esbuild, Snowpack и Vite.
— Реализации функций describe, it, beforeEach заменена соответствующими реализациями из jest-circus.
— Теперь используется новая реализация для мока таймеров. В очень редких случаях они могут сломать тесты, но есть возможность отката на старую версию с помощью jest.useFakeTimers("legacy").
— Изменено дефолтное тестовое окружение на node. Для возврата к старому поведению нужно использовать опцию "testEnvironment": "jsdom".
— Изменена логика работы функции done. Её коллбек нельзя вызвать более одного раза и нельзя комбинировать вызов done с возвратом промиса. Блоку describe запрещено возвращать какие-либо значения.
— Модули, загружающиеся с помощью опций testEnvironment, runner, testRunner и snapshotResolver, теперь транспилируются.
— Удалены задеприкейченные методы jest.addMatchers, jest.resetModuleRegistry, jest.runTimersToTime.

#testing #tool #release

https://jestjs.io/blog/2021/05/25/jest-27