ну и что бы не забывали что-то обязательное делать надо делать удобные интерфейсы

Слушай, я пирамиду правильно понял, типа не нужно покрывать юнитами то что покрыли приемочные?

не совсем.

Меня терзают сомнения

пирамида она про экономику

маленькие юнит тесты относительно дешево писать и относительно дешево поддерживать. e2e тесты оч дорого писать и прям пиздец дорого поддерживать (в сравнении с юнитами). Ну и между этими уровнями есть еще куча всяких.

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

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

При этом выгодно e2e делать так, что бы можно было их запускать на проде.

при этом есть такая практика (в живую пока не встречал...) - спуск тест кейсов вниз по пирамидке.

do something
do something else
if (some condition) {
   do something third
}
other stuff 

Вот тут у тебя есть только одно место где результат зависит от условия.

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

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

маленький трук как можно упростить тестирование тупо за счет перераспределение кода

Блин, чёт не понял(

еще важный момент - прекондишен. То насколько связана твоя система будет сильно влиять на твои возможности в плане удобства тестирования.

скажем один из толчков у меня к осознанию "как правильно сущности дробить" была проблема с управлением прекондишенами на одном из проектов. Мол что бы собрать весь граф объектов для одного тест кейса (приемочный тест апишки) надо было прям много чего сделать. В итоге у тебя на 3 строчки теста было 30 строк установки прекондишенов

это дико не удобно и бесит

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

ну смотри... ты в тестах что хочешь проверить? поведение в разных ситуациях?

если у тебя линейный код без условий:

one()
two()
three()

то у тебя тут только одна ситуация и нет других вариантов. Один позитивный тест кейс закроет все поведение.

Вариации же поведения для one должны покрывать тесты этого самого one

мы так тоже прикрывались пока из-за размеров не пошли проблемы с учетом всех фикстур для разных тест кейсов

one()
two()
three()

Ну да. Я просто не понял первый пример, если мы не зашли в if то это один результат, а если зашли то другой

Как это можно одним тестом закрыть? Или я тебя не так понял

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

Не совсем понял концепцию спуска)
Без этой концепции я бы не стал покрывать это место юнитами?