Задать вопрос
Robur

Robur

Знаю больше чем это необходимо
Ответы пользователя по тегу Модульное тестирование

  • Как протестировать атрибут компонента, если это функция?

    Robur
    @Robur
    Знаю больше чем это необходимо
    "атрибут компонента" не тестируется. Тестируется какая-либо логика.
    Если вы хотите протестировать саму функцию, то выделяете ее в отдельную функцию и пишете для нее тест
    как-то так

    function changePage(page) {
callFunction(page)
}

<Component 
 changePage = {changePage}
/>


///где-то в тестах пишете тест для changePage.
    Ответ написан
    Комментировать
    Комментировать

  • Как автоматически сгенерировать тесты для всех vue компонентов?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Посмотрите в сторону тестирования со снепшотами. Вроде jest умеет, не знаю, насколько это работает с vue.

    А вообще:
    Не проверять же полностью все приложение после каждой минимальной правки.

    Если у вас приложение написано грамотно, то минимальная правка в компоненте должна затрагивать только логику этого компонента (если вы не поменяли его внешнее api - тогда это затронет и другие, но шанс что это сломает уже их логику - минимален).
    Поэтому да - все не проверять, после каждой правки вам достаточно проверить только сам этот компонент. Если у вас компоненты не на 1000 строк, то скорее всего вы и так все проверите в процессе разработки.

    Если более формально - то есть storybook, где вы вообще девелопите каждый компонент по отдельности, изолированно и проверяете его по сути в процессе девелопмента. Он позволяет явно описать разные стейты компонента и быстро их проверить.

    Вообще важность тестирования для UI компонентов крайне преувеличена, имхо. Большая часть упавших тестов в юай - не потому что ими пойман какой-то баг, а потому что поменялась логика и надо править тесты. Это как раз тот случай когда тесты работают в минус и в юай его доля крайне велика.
    Ответ написан
    3 комментария
    3 комментария

  • Как протестировать компоненет react?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Чтобы что-то протестировать, надо решить что вы будете тестировать.
    Чтобы решить что вы будете тестировать, надо найти что может внезапно поломаться.

    Что вы хотите протестировать в этом компоненте такого, что
    1. относится к логике этого компонента
    2. может незаметно сломаться
    3. настолько важно чтобы окупить затраты по написанию-сопровождению теста?

    присваивание переменной? это ломаться не должно.
    Работу .map (тот пример что вы описали)? это внешняя логика, да и вообще - встроенный функционал.
    То что в Recipe вы передаете recipe? это не может сломаться, пока вы сознательно не удалите. В этот момент тест тоже станет не валидным, и он вам ничем не поможет, его надо будет менять.

    В общем - не надо его тестировать. Разве что для тренировки, попробовать как оно.
    Ответ написан
    Комментировать
    Комментировать

  • Как ускорить прохождение unit-тестов на JS?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Интеграционный тест с поднятием/сбросом двух баз данных в докер контейнерах и динамической загрузкой всех файлов аппы для построения контейнера DI - секунд 15 - инициализация всего этого добра, дальше сам suite, как повезет. секунд 10 в среднем (около 10 тестов внутри).
    Это запросы, записи в базу, получение ответов, построение проекций, запись во вторую базу и прочее.

    Юнит тесты - 20-70ms на suite, там до 10 тестов в каждом. Тайпскрипт + jest.

    Это на локальном ноуте где ide, браузер, разные виртуалки и так далее. На сервере быстрее.

    Если у вас 10 секунд на юнит тест - то что-то явно идет не так. Скорее всего инициализация окружения столько времени занимает, что там происходит - вам надо разбираться детально.
    Ответ написан
    2 комментария
    2 комментария