Речь в посте как раз про тесты через код, и они не отменяют ручное тестирование. НО, они помогают, в том числе, оптимизировать время QA на проведение регресса в дальнейшем.
Сильно зависит от проекта. Для какой-нибудь npm библиотеки очень важны юнит-тесты, для многих внутренних небольших проектов не так важны E2E и скриншотные, как интеграционные и юнит. В чистом виде E2E тесты довольно ресурсно-затратные для написания, поэтому их на моей практике пишут достаточно редко.
Для интеграционных тестов подойдет и Cypress (или другое решение, которое умеет в headless режим работы), с этим полностью согласен. У нас на некоторых внутренних проектах компании его успешно используют. Но все же интеграционные это про тестирование компонентов (а не всего приложения), и компонентное тестирование на мой взгляд выигрывает RTL: сложность и написания, скорость выполнения, API библиотек (субъективно, но все же). Поэтому в Самокате как основное решение для интеграционных тестов мы выбрали именно этот вариант.
Про E2E, в чистом виде, я на своей практике не встречал. Всегда были подготовлены стенды внешних API или избегались кейсы, которые могут заэффектить прогоны следующих тестов (типа, регистрация пользователя).
Про E2E, в чистом виде, я на своей практике не встречал. Всегда были подготовлены стенды внешних API или избегались кейсы, которые могут заэффектить прогоны следующих тестов (типа, регистрация пользователя).