Независимая от бекенда разработка и написание тестов почти никак между собой не >связаны.
Согласен.
Да и зачем для каждого теста поднимать весь этот сервер со всеми моками роутов (а исходя из статьи вы запускаете сервер именно в сетап-файле, который выполняется перед запуском каждого тест-файла)..?
Нет, сервер запускается 1 раз. На текущий момент у меня всего около 400 тестов ~ 1 минуты, и пока просадка не замечена (что может объясняется малым количеством тестов). Тут надо провести тесты, мокирование внутри теста - то же не бесплатное.
в ваших тестах при таком подходе не описана имплементация мока запросов, что усложняет координацию во время добавления/изменения/удаления/рефакторинга/
...
Каким образом ваш подход овер мока запроса в тесте позволяет тесту стать «чище»
Хм, я имел ввиду, что мы производим действие (клик по кнопке поиска) и проверяем, корректность рендера ответа, не проверяя параметры функции (этим пусть занимается TS). У нас на проекте, не часто требуется мокировать функции под разное использование, поэтому из теста убирается код мокирования функции и это я назвал "чистотой".
А вот по этому поводу я как раз и писал про переиспользование фикстур между реализацией msw-обработчиков и тестами. Либо вы не дочитали, либо не так поняли :)
Я понял =) Да подход рабочий, как раз для проверки рендера они импортируются. И да, получается, что остается только описать мок функции и всё наше обсуждение будет закончено =)
...реализации обработчика запросов в конкретном обработчике msw (как будто бы не очень хотелось получить связанность между msw, который используется для dev-режима и тестами, не так ли?)
Это пожалуй, самый важный момент, я бы сказал киллер аргумент =) Тут мне возразить нечего, по уму, да, тесты надо изолировать от внешних зависимостей, но тогда надо бы убрать TS, createTestingPinia, msw и тд. - скажем так, на это зло я пошел намеренно осознавая последствия =).
Подытожу: 1 - спасибо за комментарий, вы заставили задуматься о возможной будущей проблеме времени выполнения (и пока тестов не много можно поправить =)) А так же про разделение ответственности, пожалуй еще раз взвешу плюсы и минусы.
2 - msw можно использовать в тестах, но не обязательно, как и использование любого другого инструмента имеет свои сильные и слабые стороны.
3 - Мне очень импонирует ваш подход в разделении ответственности, буду рад продолжить обсуждение =) Можете описать как у вас организовано unit тестирование, как разбросано по папочкам, сколько тестов и время их выполнения.
Благодарю). Вы правильно заметили про контрактное программирование. Изначально, все было как вы описали в каждом тесте - мок запросов. Но потом понадобилось разрабатывать независимо от бекенда и тут подвернулся msw. Как мне показалось писать мок в msw, а потом еще и в тесте - расточительно и было принято решение все мокирование вынести в отдельный модуль, который построен над msw, бонусом получил удобную возможность работать с заголовками, в частности внутри теста, что сохраняет понятность и то это не всегда нужно.
Также в некоторых случаях лучше проверять отображение ответа (тот же список пользователей), а не вызов функции получения данных, так что в этом плане тесты становятся чище.
Пока такая схема работает, продолжаю вести наблюдение =)
@ArutaGerman Спасибо за комментарий. С 1 утверждением согласен отчасти. Нужно искать компромисс. Например стабить элементы UI библиотеки, как мне показалось, нормальная идея, так как не совсем ясно как задавать состояние, к примеру el-select. C ShallowMount да согласен, заменю в статье на mount, так как в реальном коде было больше компонентов и контракт с ними был не сильно важен, и в статье это ускользнуло. Тем не менее, на текущий момент, мне кажется, что стабить дочерние компоненты это хорошее решение, которое позволяет писать более простые тесты. 2. Вы правы, это можно вынести. Добавлю в статью. 3. Тут, как вы правильно заметили, на любителя. На мой взгляд, явное лучше неявного, а то так и до автоимпортов, как в nuxt можно докатиться =) PS: затупил и не в ответ заслал комментарий, извините.
Спасибо, за развернутый ответ. Есть над чем подумать
Согласен.
Нет, сервер запускается 1 раз. На текущий момент у меня всего около 400 тестов ~ 1 минуты, и пока просадка не замечена (что может объясняется малым количеством тестов). Тут надо провести тесты, мокирование внутри теста - то же не бесплатное.
Хм, я имел ввиду, что мы производим действие (клик по кнопке поиска) и проверяем, корректность рендера ответа, не проверяя параметры функции (этим пусть занимается TS). У нас на проекте, не часто требуется мокировать функции под разное использование, поэтому из теста убирается код мокирования функции и это я назвал "чистотой".
Я понял =) Да подход рабочий, как раз для проверки рендера они импортируются.
И да, получается, что остается только описать мок функции и всё наше обсуждение будет закончено =)
Это пожалуй, самый важный момент, я бы сказал киллер аргумент =) Тут мне возразить нечего, по уму, да, тесты надо изолировать от внешних зависимостей, но тогда надо бы убрать TS, createTestingPinia, msw и тд. - скажем так, на это зло я пошел намеренно осознавая последствия =).
Подытожу:
1 - спасибо за комментарий, вы заставили задуматься о возможной будущей проблеме времени выполнения (и пока тестов не много можно поправить =)) А так же про разделение ответственности, пожалуй еще раз взвешу плюсы и минусы.
2 - msw можно использовать в тестах, но не обязательно, как и использование любого другого инструмента имеет свои сильные и слабые стороны.
3 - Мне очень импонирует ваш подход в разделении ответственности, буду рад продолжить обсуждение =) Можете описать как у вас организовано unit тестирование, как разбросано по папочкам, сколько тестов и время их выполнения.
Благодарю). Вы правильно заметили про контрактное программирование. Изначально, все было как вы описали в каждом тесте - мок запросов. Но потом понадобилось разрабатывать независимо от бекенда и тут подвернулся msw.
Как мне показалось писать мок в msw, а потом еще и в тесте - расточительно и было принято решение все мокирование вынести в отдельный модуль, который построен над msw, бонусом получил удобную возможность работать с заголовками, в частности внутри теста, что сохраняет понятность и то это не всегда нужно.
Также в некоторых случаях лучше проверять отображение ответа (тот же список пользователей), а не вызов функции получения данных, так что в этом плане тесты становятся чище.
Пока такая схема работает, продолжаю вести наблюдение =)
@ArutaGerman Спасибо за комментарий.
С 1 утверждением согласен отчасти. Нужно искать компромисс. Например стабить элементы UI библиотеки, как мне показалось, нормальная идея, так как не совсем ясно как задавать состояние, к примеру el-select. C ShallowMount да согласен, заменю в статье на mount, так как в реальном коде было больше компонентов и контракт с ними был не сильно важен, и в статье это ускользнуло.
Тем не менее, на текущий момент, мне кажется, что стабить дочерние компоненты это хорошее решение, которое позволяет писать более простые тесты.
2. Вы правы, это можно вынести. Добавлю в статью.
3. Тут, как вы правильно заметили, на любителя. На мой взгляд, явное лучше неявного, а то так и до автоимпортов, как в nuxt можно докатиться =)
PS: затупил и не в ответ заслал комментарий, извините.