Комментарии 3
Несколько моментов за которые зацепился глаз:
Зачем стабать вручную дочерние компоненты, если это уже сделал shallowmount? Если это только из-за слота, так дефолтный слот можно рендерить с помощью renderStubDefaultSlot
Без явной необходимости не стоит стабать вручную дочерний компонент и не будет (почти) проблем в будущем при измении их контрактов, потому что тест будет смотреть на реальную реализацию компонента, а не его ручной стаб в тесте.
Имхо. Очень мало ситуаций когда надо стабать вручную компоненты. Как пример на скорую мысль, приходит только: у тестируемой сущности нет четкого шаблона (тесты в ядре vue) или надо настабать не дефолтные слоты, что может решиться использованием mount, а не shallowmount.
Сброс моков: для примера это ок, чтобы наглядно было, но в проекте это можно вынести в глобальную область, т.к., когда 1 компонент, это всё интересно и прикольно, но, когда из раза в раз приходится писать, утомляет. Это вкусовщина, на самом деле. Упоминаю на всякий случай: вдруг не в курсе возможности и это можно описать отдельным абзацем на самом деле.
Часть импортов из vitest можно не делать: работает по дефолту, т.к. всегда доступно в тестах, если настроить vite.config
@ArutaGerman Спасибо за комментарий.
С 1 утверждением согласен отчасти. Нужно искать компромисс. Например стабить элементы UI библиотеки, как мне показалось, нормальная идея, так как не совсем ясно как задавать состояние, к примеру el-select. C ShallowMount да согласен, заменю в статье на mount, так как в реальном коде было больше компонентов и контракт с ними был не сильно важен, и в статье это ускользнуло.
Тем не менее, на текущий момент, мне кажется, что стабить дочерние компоненты это хорошее решение, которое позволяет писать более простые тесты.
2. Вы правы, это можно вынести. Добавлю в статью.
3. Тут, как вы правильно заметили, на любителя. На мой взгляд, явное лучше неявного, а то так и до автоимпортов, как в nuxt можно докатиться =)
PS: затупил и не в ответ заслал комментарий, извините.
Пожалуйста, старайтесь использовать shallowmount и только потом mount, когда он реально нужен или без него никак не получается, т.к. это убережет от кучи проблем, связанных с mount, аля "сломалось что-то на 3-4 уровня вниз, а падает именно этот тест и теперь ищи и разбирайся почему".
Не понятна проблема стабать состояние компонента ui? Он же по дефолту имеет значения пропсов и в тестируемом компоненте он маунтится именно с дефолтным состоянием изначально. Если же нет, то надо понимать откуда берется это состояние:
- если из глобального стейта, то перед выполнение теста установить нужное значение в стейте
- если в ходе работы логики тестируемого компонента - вообще не стоит переживать, т.к. это поведение компонента и это даже можно протестировать
- если хардкодом прописано значение пропса - можно стабать вручную
Но, в любом случае, по возможности, надо стараться по минимуму стабать руками компоненты, т.к. это несет много банальных рисков: "добавили фичу / исправили баг в компоненте, а тест не обновили".
Как я начал писать unit тесты для Vue компонентов