Итак, мы дошли до обсуждения пирамиды! И начать предлагаю с обсуждения терминов.
Я с недавнего времени стараюсь избегать названий "юнит", "интеграционные" и "e2e".
Понятия настолько расплывчаты, что каждый подразумевает что-то свое под каждым из них.
Наибольшие проблемы возникают с интеграционными. Вот например в яндексе считают что selenium тесты которые ходят и тестируют их продакшн – интеграционные 🤷♂️ youtube.com/watch?v=dflmpq…
Интеграцио́нное тести́рование (англ. Integration testing, иногда называется англ. Integration and Testing, аббревиатура англ. I&T) — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. (wikipedia)
А юнит тесты — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки.
И вот тут уже возникает коллизия. Юнит тесты могут тестировать группу модулей (> наборы из одного или более программных модулей ) – но все еще не превращаются в интеграционные.
То есть нету четкого разграничения когда юнит тест стал интеграционным.
Тоже самое происходит и с e2e. Ведь по-сути все наше приложение это тоже группа модулей. Соответственно любой e2e тест это интеграционный, но не наоборот.
Пример! Мы пишем библиотеку которая наверх вываливает функции.
Например date-fns (кстати вообще не понимаю почему все писяют кипятком от нее).
Наши e2e тесты это будет просто вызов функции. Потому что мы в тестах работаем с кодом точно так же как наши пользователи.
Но абсолютно точно такой же тест на точно такой же код в любом приложении – уже никак нельзя назвать e2e.
Тоже самое происходит с UI тестами. Для вас покрыть фронтенд через selenium это e2e, а для какого-то огромного сервиса у которого таких фронтов 86 – уже нет.
У каждого продукта (или каждой команды) есть своя зона ответственности.
Например для меня в material-ui это будут тесты на компоненты. И для меня же, когда я пишу свой стартапчик (а я пишу) – уже нет. Хотя в теории у меня может быть точно такой же компонент и точно такой же тест
И внутри каждой зоны ответственности мы можем писать 3 вида тестов: black box, grey box и white box.
То есть когда наши тесты знают все про реализацию, не знают ничего или знают чучуть.
Так вот white box тесты в моей картине мира приносят только проблемы.
Ой, я ж забыл написать самое важное!
Если говорите со своей командой о тестах, обязательно убедитесь что вы говорите об одном и том же.