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

>это значит разраб не доработал?

Это значит, что разрабу лень покрывать фичу тестами и/или он не разбирается в тест-дизайне. Обычно девелоперы пишут 1-2 хэппи пас теста и на этом всё. Соответственно, много юзкейсов остаются непокрытыми девелоперскими тестами и о них должен думать тестировщик.

>вы проговариваете с разрабом что автоматизировать QA чтобы не перехлёстывать тесты?

Об этом много пишут в статьях про пирамиду тестирования, но на деле это буллшит. Потому что девелоперы будут рефакторить/удалять свои тесты и не будут вас об этом уведомлять. Соответственно, тестовое покрытие со временем будет уменьшаться. Лучше 2 раза протестировать один кусок кода на разных уровнях, чем понадеяться на девелоперов и протестировать 0 раз

Нет, потому что дублирование проверок будет не полным, а даже если и будет - это скорее хорошо, чем плохо.

Пирамида тестирования так-то вообще не про это.

В том числе и про это)

Она про то, что бы держать тесты на том же уровне, что и объект тестирования.

У юнитов и энд ту энд тестов объекты тестирования сильно разные.
Даже если кодовая база тестируемый логики сильно пересекается.

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

По поводу юнит-тестов (точнее, компонентных) встретился с таким подходом: в паке с интеграционными тестами лежат тесты со ссылками на некоторые компонентные. Таким образом, есть трассировка между некоторыми тест-кейсами и покрывающими их компонентными тестами. Звучит вроде логично, но выглядит странно.

Да в общем-то нет, потому что количество состояний объекта низкого уровня не отражает количество его состояний, задействованных в end-to-end сценариях.

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

Ну вот сам Фаулер большими буквами пишет *Avoid Test Duplication* https://martinfowler.com/articles/practical-test-pyramid.html#AvoidTestDuplication. Немало авторов понимают это по-своему и игнорируют заявление If a higher-level test gives you more confidence that your application works correctly, you should have it, в результате чего сводят всю концепцию к “тестируйте всю бизнес-логику на уровне юнит тестов и немножко потестируйте интеграции, тесты никогда не дублируйте”

Ну, в целом да, убедил.
Но для продолжения холивара всё равно вброшу. :)

Сам Фаулер большими буквами пишет: избегайте дублирования тестов.
А потом приводит пример:
Writing a unit test for a Controller class helps to test the logic within the Controller itself. Still, this won't tell you whether the REST endpoint this Controller provides actually responds to HTTP requests. So you move up the test pyramid and add a test that checks for exactly that - but nothing more. You don't test all the conditional logic and edge cases that your lower-level tests already cover in the higher-level test again. Make sure that the higher-level test focuses on the part that the lower-level tests couldn't cover.

И тут мы получаем уже пространство для холивара про дефиниции, потому что:  
Два теста (на контроллер и на REST API вокруг этого контроллера) могут использовать сильно дублирующуюся кодовую базу.
Но при этом объект тестирования у них разных, скоуп тестирования у них разный и, тащемта, даже инпуты и аутпуты у них будут разные.

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

Благодарю! @azshoo

Ну пример с контроллером у него так себе) Сложность написания и время работы тестов на контроллер и на эндпоинт практически одинаковая, поэтому обычно можно обойтись только компонентными тестами на эндпоинт и не строить пирамиду на ровном месте
А вот валидация веб-форм - это уже поинтереснее. Можно тестировать валидацию на уровне юнит тестов в JS, можно на уровне е2е тестов в браузере, плюс юнит и е2е валидации на бэке. Итого - 4 уровня, на которых можно написать тесты на одну и ту же логику, и каждый уровень имеет свои минусы. Потому что надеяться на то, что девелоперы покрыли все сценарии валидации юнитами и не похерили эти юниты - такое себе, но писать е2е тесты на валидацию в браузере - очень дорогое удовольствие

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

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

😁 Да нет, есть такие проекты с хорошим качеством

Я и не говорю, что их нет.

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

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

Проблема "не похерили тесты" решается через codecov и принудительное ревью от QA при изменении тестов.
Но да, я не работаю в командах, где у куак нет доступа к коду, поэтому в моём уютном мирке пирамида нормально работает.