Кто как пишет тесты? снизу вверх или сверху вниз? интеграционные

тесты покрывают большую часть кода. и юнит тестами можно закрыть оставшиеся граничные случаи.

если же писать на всё юнит тесты, то они начнут перекрывать как друг друга, так и интеграционные тесты. будет избыток тестов. есть ли в этом смысл?

ответ - никак, тесты не пишем))

и каждый раз вручную тестишь?

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

при этом в роутах сервисы и репозитории мокнуты?

обычно поднимаю тестовую бд поскольку так быстрее

+ только стресс-тесты)

юзеры потестят)

Это уже полноценные е2е

согласен, но просто там обычно тестится только отдельные роуты а не все вместе, и не уверен что это можно назвать полноценным е2е

e2e — это вместе с фронтом

не совсем же?

Это тестирование приложения от начало до конца. Если ничего не покается, и тестируется все от хттп сервера для внешних сервисов, типа БД, то полное тестирование и выходит. Фронта вообще может не быть

вопрос-то такой: е2е тесты дают большое покрытие кода. далее остается юнит тестами закрыть граничные случаи. если же писать на все модули юнит тесты, а потом еще и интеграционные/е2е, то получится избыток тестов, они начнут перекрывать уже протестированное. есть ли в этом смысл? или лучше на е2е сфокусироваться.

можно ити на компроммис и юнитами покрыть критическую бизнес логику с десятком разных тестов на каждую фичу, а все остальное покрыть интеграционными/е2е на 2-4 теста

можно и реплику даже, просто доп.сервисом броадкастить для синхронизации. юзаю тесты прямо на проде в moleculer, выставляя в сервисах флаг version, потом в брокере call('v3.something.list'), хз как можно еще упростить работу

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

а что вы в итоге от этого получите?

Зависит от того, тестами покрываем легаси или green field

Хорошую архитектуру green field проекта) При правильной декомпозиции можно получить вообще полное покрытие юнитами (кроме entry point файла, который "боевые" зависимости инжектит в апп)

а кто тогда проверяет что приложение работает?))

Только е2е)

вас понял)

если не легаси?

Тогда сразу с юнитами - на каждую функцию (желательно) - я именно так пишу пакеты на нпм)

когда напишем е2е тесты, то они начнут избыточно перекрывать юнит тесты. разве это норм?

Цели у тестов немного разные. е2е тесты не документируют модули и не помогают с их рефакторингом

Норм для green field, ибо, как я писал выше: https://t.me/nodejs_ru/687542

не понял насчет рефакторинга. если е2е тест прошел и покрытие кода не снизилось, то значит рефакторинг успешен, раз нет

Да, е2е тест не знает, какие функции каких юнитов он тестирует. Сегодня одни, завтра другие. Он проверяет работу приложения, выполнение в нем сценариев его использования. Юнит тест покрывает юнит, показывая, что этот юнит работает так, как ожидается, и описывая эти ожидания, для его пользователей (других юнитов), позволяя понимать и рефакторинг этот юнит без опасений, что сломается его использование

Ты предлагаешь е2е тестами делать полное покрытие?

е2е тесты дают большое покрытие. остатки можно закрыть точечными юнит тестами

А чем юнит от модуля отличается? Что такое модульное тестирование тогда?

У них задачи и покрытие разное

Юнит - это модуль по английски

Package (из npm) - это я под модулем понимаю ЗЫ: есть в английском module/extension - так что не надо

Суть ведь в том, чтоб покрыть тестами весь public API из package npm

Модули приложения могут не публиковаться как пакеты, но не суть, да

Так вот. Я предпочитаю модульное тестирование юнитам)

Без англицизмов это утверждение фактически звучит как "Я предпочитаю модульное тестирование модулям")

У меня юнит - это функция. Если я её не экспортирую из моего package, то она покрыта тестами публичного апи либы 🤷‍♂

а как покарыто публичным апи если она не експортируется?)

Внутри публичного апи вызывается во всех возможных вариантах