Довольно странные суждения и выводы. Вы приводите иллюстрацию пирамиды, но совершенно не понимаете сути образования этой пирамиды и пытаетесь трактовать ее по–своему, на основе чего даёте ответ на вопрос заведомо некорректный.
Пирамида — это свойство которое образуется самостоятельно при разделении тестов на цели и зоны ответственности и выражено оно соотношением стоимости к качеству, меньше стоимость и выше качество. Не нужно пытаться собственноручно выстроить данную пирамиду, руководствуясь лишь тем что UI-тестов должно быть меньше, чем Unit-тестов — ничего хорошего из этого не выйдет.
Ваш вопрос «С чего начать?» некорректен тем, что вы оперируете совершенно разными видами тестов, цели которых очень сильно отличаются. И каждый вид тестов не должен пересекаться с другими и уж тем более нести ответственность за других. Если писать только E2E-тесты, то мы можем отвечать только за то что определённый сценарий действий работает, но не за корректность всех данных по пути этого сценария. Например, если вдруг каким-то образом у вас E2E-тесты начали нести ответственность и за данные на каждом шаге, то спешу порадовать — вы начали писать тесты других видов за счёт E2E-тестов, что само по себе дорогое удовольствие и противоречит пирамиде с которой вы начали. Любые тесты писать необходимо тогда, когда дело доходит до зоны ответственности, которую необходимо покрыть тестами, а не когда вздумается.
Просто для любого нового проекта это абсолютно нормальная ситуация — в какой-то момент понять, что изначальная архитектура или затея вышла не слишком удачной — и что нужно всё (или практически всё) переделывать.
Это абсолютно не нормальная ситуация, это уже вопрос к компетентности и уровню команды, и говорит только о том что с ней явно что-то не так. Использовать это как аргумент против Unit-тестов совершенно глупо. Каждый ответственный разработчик каким-либо образом проверяет работоспособность своего кода, вопрос только лишь в том каким образом? Поднимает целиком всю систему на каждый чих и ручками проверяет? Что-то сильно дорого выходит, не так ли? Это еще ладно если такая возможность вообще есть, а если ее нет? Интересно было бы узнать как обойтись в таком случае без Unit-тестов.
Пирамида — это свойство которое образуется самостоятельно при разделении тестов на цели и зоны ответственности и выражено оно соотношением стоимости к качеству, меньше стоимость и выше качество. Не нужно пытаться собственноручно выстроить данную пирамиду, руководствуясь лишь тем что UI-тестов должно быть меньше, чем Unit-тестов — ничего хорошего из этого не выйдет.
Ваш вопрос «С чего начать?» некорректен тем, что вы оперируете совершенно разными видами тестов, цели которых очень сильно отличаются. И каждый вид тестов не должен пересекаться с другими и уж тем более нести ответственность за других. Если писать только E2E-тесты, то мы можем отвечать только за то что определённый сценарий действий работает, но не за корректность всех данных по пути этого сценария. Например, если вдруг каким-то образом у вас E2E-тесты начали нести ответственность и за данные на каждом шаге, то спешу порадовать — вы начали писать тесты других видов за счёт E2E-тестов, что само по себе дорогое удовольствие и противоречит пирамиде с которой вы начали. Любые тесты писать необходимо тогда, когда дело доходит до зоны ответственности, которую необходимо покрыть тестами, а не когда вздумается.
Это абсолютно не нормальная ситуация, это уже вопрос к компетентности и уровню команды, и говорит только о том что с ней явно что-то не так. Использовать это как аргумент против Unit-тестов совершенно глупо. Каждый ответственный разработчик каким-либо образом проверяет работоспособность своего кода, вопрос только лишь в том каким образом? Поднимает целиком всю систему на каждый чих и ручками проверяет? Что-то сильно дорого выходит, не так ли? Это еще ладно если такая возможность вообще есть, а если ее нет? Интересно было бы узнать как обойтись в таком случае без Unit-тестов.