Время пришло! Тот самый тред о том, почему пирамида это пережиток прошлого.
Вот только важно: Под юнит тестами тут я подразумеваю white-box тесты на самые маленькие части нашей системы (компонент, функция, и т.д.)
Немного истории. Пирамида начинает свое начало примерно в 2008 году.
Вот пруф benhutchison.wordpress.com/2008/03/20/aut…
И если вы ознакомитесь со статейчками о том почему же все таки именно так необходимо писать тесты. Например от Мартина Фоулера (martinfowler.com/articles/pract…)
То вы увидите только 2 аргумента:
Юнит тесты писать проще
Юнит тесты бегают быстрее
Действительно писать юнит тесты проще?
Ха-ха-ха, не смешите мои тапочки. Если мы говорим про тот тест, где у вас 2 строчки самого теста и 50 строк кода на то чтобы замокать зависимости? Серьезно?
Современные e2e раннеры для фронтенда типа cypress от вас требуют просто запустить ваше приложение. И все, больше ничего не надо.
У вас открывается браузер, дебажьте тесты, используйте дев тулзы. Вам тут и тайм-тревелинг и все что угодно.
vimeo.com/237527670
Помимо всего прочего, юнит тесты от вас требуют определенной инфраструктуры.
Типо DI, которые разработчики начинают использовать только ради тестов. Но не спешите полыхать, я все объясню.
Мой поинт: попробуйте написать юнит тесты в продукте где никто не готовился к этому :)
Юнит тесты бегают быстрее
Ну как бы хрен поспоришь. Вот только вспоминаем 2008 – никакого докера, из CI только jenkins. А у вас тесты бегут 2 часа. Вполне логично что таких ситуаций следует избегать.
Но мы же не в 2008! 21 век надворе – очнитесь.
В cypress у нас было 2000 cypress тестов. C покрытием >95%. И эти тесты бежали 2 минуты на 15 машинах в параллели.
Да, на локали не запустить – но просто пушиш коммит и ждешь CI.
Ну а если вам жалко 1000 долларов на нормальный CI – извините это диагноз. Нанимайте 5 manual QA.
Окей, но что же там по поводу фокусности тестов. Я абсолютно не отрицаю необходимости покрытия бизнес логики отдельно.
То есть юнит-тесты на вашу кор бизнес логику написать необходимо. Почему и не противоречу ли я сам себе? - отвечаю дальше:
Я сегодня уже делал твит про зоны ответственности.
Итак вашу бизнес логику вы должны изолировать от UI.
И не для того чтобы тестировать проще было, а чтобы ее можно было переиспользовать в будущем. То есть для того чтобы не менять ее когда будет рефакториться UI
И соответственно на уровне бизнес логики вы пишите тесты.
Вы пишите опять e2e тесты, как бы представляя что ваша бизнес логика – это отдельный проект. Но по-факту это могут быть jest тесты которые вы привыкли называть юнитами.
Хотя по-сути это e2e на другом уровне.
Тоже самое с переиспользуемыми компоненты.
Какие-нибудь части UI (кнопка, таблица), которые в теории могут быть вынесены в отдельный проект и зашарены.
Вы их покрываете с учетом того, что они будут использованы абсолютно в разных контекстах. Но это опять e2e на другом уровне.
Да тесты будут пересекаться. И это нормально, на 1 уровне вы проверяете работоспособность БЛ.
На другом проверяете что итоговый продукт правильно работает с БЛ.
Но возникает интересный вопрос: А сколько собственно чистой бизнес-логики вы пишите?
Я очень сомневаюсь что у вас наберется и 20% такого кода в проекте. В основном мы просто берем готовые компоненты и как-то их комбинируем между собой.
Так на кой ляд нам писать юнит-тесты, если 80% нашего кода – это чистого рода интеграции.
(спорное утверждение согласен, смотрите срач в ответах)
Если вы думаете что e2e тесты, которые запускаются в браузере ненадежные – вас возможно покусали xpath-ы.
Это ужасный антипаттерн который юзают автоматизаторы, короче эта штука которая ищет элементы в доме через дерево.
И это реально бред, потому что любое изменение структуры дома, даже которое не влияет на внешний UI приводит к поломке.
Как это решить мы уже обсуждали. Использовать a11y теги, текст или data-test-id для доступа к элементам.
И ваааау – ничего не падает.
И кстати это касается и бекенда. Вообще представить не могу как писать бек без полноценного тестирования API.
Но это уже совсем другая история.
Вообще я уже задолбался тут писюкать.
Вывод из этого такой: выше забираться по пирамиде вообще не сложно. Но добавляет капец как много надежности нашим тестам.
Жду срачей C: