Клуб технических практик. Тема: Рекомендации по 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 Рекомендации по использованию снапшотов
• Снапшоты должны использоваться аккуратно и только в тех местах, где они действительно полезны.
• Документ с рекомендациями может быть полезен для команд, но не должен быть обязательным для внедрения.
• Важно, чтобы команды имели общую концепцию подходов к тестированию, чтобы избежать разнобоя в подходах.
