есть проще способ об этом думать.

У тебя должны быть приемочные тесты. Хочешь ты того или нет - но без приемочных тестов будь у тебя хоть 100% покрытие юнитами это не особо показатель "внешнего качества" (которое для пользователей, о том что у них все фичи все еще на месте).

Если у нас есть скажем фича "обновить профиль" или "обновить локейшен" мы в любом случае будем писать как минимум на позитивные кейсы тесты для этих фич просто что бы знать что фичи еще с нами, живые и ими можно пользоваться.

И да такие тесты будут ходить в базу, могут выполняться ажно секунду на тест кейс, и главное что их обычно не очень много. Ну то есть их столько же сколько и фич у тебя в приложении по сути.

Дальше интересно то, что если у тебя нет if-ов там в логике, то в целом один проход этого приемочного теста закроет тебе весь код и необходимости в юнитах не будет.

А вот есть у нас появляются if-ы причем не один и не два, и там логика какая сложная или сложные преобразования данных требования к которым тебе было бы хорошо бы закрыть тестами, то тут уже на сцену выходят юниты. И очень выгодно эту логику выделять куда-то (в VO, в какие-то отдельные сервисы-функции без зависимостей) дабы минимизировать необходимость подменять зависимости в тестах.

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

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

imperative shell / functional core

ну и да, речь пока идет о тех зависимостях которые передаются неявно.

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

А можно сделать сервис который достает штуки из базы и кладет их на вход в VO который представляет собой коллекцию этих слотов. в итоге у тбея у логики нет никаких "внешних" зависимостей (в том плане что все приходит на вход). При этом да у тебя будут "пользователи" этого класса

в итоге там где много зависимостей не будет логики а там где логика сложная не будет зависимостей

вжух и счастье

@fes0r
> там организации всякие и группы юзеров и друзей друзей и вот по цепочке пол приложения приходится засэтапить
вот с этим не очень понятно как бороться. Может быть может помочь замена связей на идентификаторы

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

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

казалось бы у всех в резюме написано шо мол да, умею тестирование делать :D

ой да че там сложного, шо скрипт не напишешь который то что ты делаешь руками делает за тебя?

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

наверное причина этому то что в большинстве случаев процесс "тестирования" построен как "разработчик переводит задачку на QA и это не его проблема".

прост за 5 лет работы пока не видел ещё тестов нормально написанных, чтобы обо всём вот этом вот, о чём ты затираешь люди подумали
зато тестировать все по резюме умеют

Я не говорю, что интеграционные тесты дорогие. Я говорю, что они дороже юнитов, для них нужно сильно больше всего настраивать, они более хрупкие и они покрывают слишком много кода и если валятся — то найти сложнее, что именно упало. Это, конечно, не отменяет их необходимости

И сложные штуки за пределами "сохрани профиль", "нарисуй профиль" юнитами покрывать проще и вообще стоит

и все что ты перечислил это правда, вот только приемочные тесты всеравно нужны

только там тестить нечего, чаще всего ты в таких тестах увидишь дублирование реализации

это "неотменяемые" атрибуты таких тестов, поэтому стоит их количество тупо минимизировать. Опять же если иф-ов в сервисах мало - вероятность того, что разраб ошибётся меньше

end-to-end тесты могут быть не особо нужны, только на уровне "вот у нас есть 3-4 critical workflow" где прям максимально по верхам убедиться что все компоненты системы собраны, и вот это могут QA писать

Тоже правда. Это sanity check самого себя. Одно дело реализация метода на 100 строк, другое дело, что я в юните напишу f([1,2,3]) и проверю, что результат 6