Что такое компонентные тесты, и каково быть SDET'ом

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

Простите, вы считаете, что SDET это роль, которая пишет тесты?

SDET, у эппла и мелкомягких, которые заявляют, что они придумали эту роль, занимаются не автоматизацией тестирования, а автоматизацией процессов, работой над тестируемостью и обеспечением качества. Это две большие разницы, QC и дописыванием за разработчиками тестов они не заняты.

То, о чем писали вы — это недоразработчик, ну или чернорабочий в IT.

Подскажите, а вы подразумеваете навыки devops для SDET? Если да, то вы относите их к плюсам или минусам? )
Дело в том, что в компании где я работаю, SDET — это человек, которые обладает навыками разработки, тестирования и devops.
Это автономная единица, которая может создать себе рабочее окружение, установить приложение, которое будет протестировано, при необходимости написать заклушки или эмуляторы, соответственно написать тесты для этого приложения и внедрить в CI/CD цикл реального приложения.
В идеале, эта проверка должна пойти перед установнай на реальную систему.

В статье скорее описан обычный автоматизатор, который занимается не совсем обычным тестированием.