Клуб технических практик. Тема: Рекомендации по unit-тестированию Vue-приложений

#smlab #клубтехпрактик Клуб технических практик. Тема: Рекомендации по unit-тестированию Vue-приложений 00:00 Юнит-тестирование в View приложениях • Обсуждение темы юнит-тестирования в View приложениях, где компонент является сущностью, зависящей от фреймворка. • Рекомендация использовать подход, сочетающий классическое и интеграционное тестирование. 05:45 Артефакты и подходы к тестированию • Артефакты на выходе: HTML, события, вызовы внешних сущностей, взаимодействие с другими компонентами. • Тестирование поведения компонента: HTML, события, взаимодействие с другими компонентами, изменение внешнего состояния. • Запрет на проверку значений вычисляемых свойств компонента. • Важность тестирования компонента как чёрного ящика и предсказуемого окружения. 13:29 Тестирование компонентов • Обсуждение важности изолированности тестов и использования Set props только для тестирования работы компонентов и их свойств. • Компоненты должны тестироваться как черные ящики, без глубокого изучения их внутренней реализации. 20:01 Методологии тестирования • Обсуждение двух методологий тестирования: черный ящик и белый ящик. • Для фронтенда рекомендуется использовать подход черного ящика, так как внутренняя реализация компонентов часто меняется. 22:18 Тестирование бизнес-логики • Бизнес-логика, заложенная в компоненте, должна влиять на его поведение и отражаться в требованиях к компоненту. • Тестирование бизнес-логики может быть выполнено внутри компонента или как часть черного ящика. 26:04 Тестирование компонентов • Обсуждение использования функции Mount для тестирования компонентов. • Упоминается, что фреймворк не знает, что рендерит компонент, и это нужно проверять. • Упоминается блог по тестам, который может быть полезен. 30:43 Плюсы и минусы разных подходов • Использование Mount рендерит все дерево компонентов, что может привести к хрупкости тестов. • Shell Mount рендерит только тестируемый компонент, что делает тесты более честными и устойчивыми. • Shell Mount позволяет описать контракт с компонентом и его ожидаемое поведение. 36:10 Рекомендации по использованию Mount • Рекомендуется использовать Shell Mount для тестирования компонентов. • Если требуется проверить сложные сценарии взаимодействия компонента с пользователем или другими компонентами, можно использовать Mount. • Рекомендуется отводить отдельный блок в файле с тестами для Mount-тестов. 38:53 Поиск элементов в тестах • В тестах рекомендуется искать элементы по интуитивно понятным для пользователя сценариям, например, по кнопке с надписью "Оформить заказ". • Если элемент не доступен для прямого взаимодействия, можно использовать атрибуты Data Test ID или aria-attributes. 44:25 Приоритет поиска по атрибутам • Если атрибуты присутствуют в приложении, рекомендуется использовать их для поиска элементов. • Если атрибуты отсутствуют, можно использовать Data Test ID. 51:33 Поиск по тексту и классам • Поиск по тексту может быть использован для проверки правильности вычисления текста, но не для поиска элементов. • Классы могут меняться, но они не влияют на то, что видит пользователь. 53:28 Тестирование в изоляции и в связке с компонентами • В видео обсуждается, как тестировать компоненты в изоляции и в связке с другими компонентами. • В изоляции проще тестировать мутации и экшены, но в связке с компонентами можно увидеть, как они реагируют на изменения в сторе. 57:15 Зависимости и сайд-эффекты • В видео обсуждаются зависимости, которые могут порождать сайд-эффекты. • Если модуль содержит много логики, можно изолировать его и тестировать отдельные методы. 58:39 Стратегия тестирования и процент покрытия • В видео обсуждается, что каждая команда должна определить свой уровень покрытия юнит-тестами. • Рекомендуется покрывать тестами компоненты, входящие в U Kit приложения, компоненты, задействованные в главной дороге пользователя, и критичные для бизнеса функции. 01:02:44 Тестирование контрактов и крайних случаев • В видео обсуждаются крайние случаи и пограничные значения, которые не стоит вычищать и придумывать. • Вместо этого, лучше отдать задачу на ревью и тестирование впту, а затем, при необходимости, дописать тесты для поведения, в ходе которого выявлен баг. 01:05:34 Тестирование компонентов 01:08:31 Тестирование снапшотов 01:13:30 Рекомендации по использованию снапшотов • Снапшоты должны использоваться аккуратно и только в тех местах, где они действительно полезны. • Документ с рекомендациями может быть полезен для команд, но не должен быть обязательным для внедрения. • Важно, чтобы команды имели общую концепцию подходов к тестированию, чтобы избежать разнобоя в подходах.