Привет всем. Подскажите, как в jest протестить метод, который вызывается

внутри другого метода? openFile() покрывается, но внутри этого метода есть другой, который ну никак не хочет покрываться аналогичным способом

мне кажется, что ты тестируешь реализацию внутри компонента - это плохой тест

Tmq
AttachListItem.vue: Uncovered Lines: 99

не нужно тестировать методы/компутеды/дату и прочие внутренности компонента, нужно тестировать сам компонент. минимальный юнит в юнит тестировании вью - компонент, всё что внутри компонента - черный ящик

Tmq
AttachListItem.vue: Uncovered Lines: 99

Вместо тестирования метода тебе нужно тестировать сценарий использования компонента, при котором этот метод используется

спасибо, не очень-то понятно, как это реализовывать на практике, но будем стараться)

спасибо!

Это надо не "реализовать", а "не реализовать" :D Владимир сказал, что не делать "не нужно" - не нужно тестировать внутренность компонента, это детали его реализации. Нужно тестировать использование компонента

просто объяснение поячему такие тесты как кутебя плохо: та разбил один меод на два, и метода с именем который тестируется больше нетЮ ничего не сломалось, просто внутри работает подругому, тест у тебя упадет т.к. метода такого нет, а он падать не должен т.к. всё работает

так в этом и проблема, видимо, в самом понимании тестирования. Я в документацию смотрю, читаю, но не особо понимаю, как это реализовывать. Или не реализовывать, я уже запутался)

А что реализовать?

если есть лишних 150 баксов, рекомендую мастер классы Климова по тестированю)

Условно, мне нужно сделать покрытие кода на определенное количество %, сонар подсказывает, где и что я не протестировал и указывает на строку, к примеру выше, где метод в методе. Каким-то образом я должен удовлетворить его требования и покрыть эту строку, а вот что писать в тестах - ума не приложу

Тоже самое, что сказал Владимир, только другими словами: цель тестирования — тестировать работу компонента, описывать компонент, подтверждать корректность работы с ним, а не тестировать его внутреннюю реализацию. Пользователей компонента не волнует, как он реализован, какие там методы, выч свойства, дата и тп. Их волнует, как его использовать, как он работает. И тестируются разные сценарии использования этого компонента. Тестируется, что при определённом использовании (входных параметрах, взаимодействии снаружи) компонент даёт ожидаемый результат. Рефакторинг компонента, не влияющий на его использование, не должен приводить к необходимости переписывать тесты. А у тебя будет, так как тестируется внутренность, и любое мелкое изменение компоненат приведёт к переписыванию теста даже, если снаружи компонент не поменялся

В каком сценарии используется этот метод?

спасибо, я посмотрю информацию на счет этого)

благодарю за такой объемный и развернутый ответ. Метод используется в сценарии - произошел клик по кнопке, сработал метод по клику, внутри вызвался метод по скачиванию этого файла

А скачивание реализовано прямо тут же в компоненте?

да

Вот мы и нашли проблему) Это не должно быть частью компонента

😭

Компонент не должен думать о том, как реализовано скачивание файла. Это не его зона ответственности совсем. Это должна быть отдельная функция в отдельном модуле где-то вне компонентов.