Ряд статей + курсы универа от тестера. Из известных книг ничего назвать не смогу

Выше вроде как обсуждали, что белый/чёрные и модуььными/компонентными могут быть.

компонент = модуль = юнит в итоге можно сделать вывод что нет разницы между юнит тестами и компонентными тестами)

ну то есть, определений "юнит теста" не один десяток

Не спорю

когда народ в литературе вводил понятие черный ящик - это была метафора наличия границы, information hiding, вот это все. Никаких белых ящиков небыло. Это додумали видимо, стремление найти антоним так скажем к метафоре

Так и было. Для объяснения чёрного ящика придумали понятие белого

Как одну из практик (кажется)

ну, можно много примеров привести неудачных метафор)

есть вот например "изоляция тест кейсов" - хорошая штука.

а да, к слову... на тему ящиков. Люди по какой-то причине думают что проблема именно в коде. Ну то есть там "я знаю какие зависимости моя штука юзает"

хотя проблема именно в изоляции тест кейсов

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

ну то есть акцент именно на количестве причин по которым тест может упасть. В идеале - один тест кейс - одна причина.

что до "сколько тест кейсов должно быть" - сколько бы их нибыло - всегда будут кейсы о которых ты не подумал или не знаешь еще. А потому тебе придется остановиться в какой-то момент потому что ROI.

Еще есть неплохие практики связанные с error budget из SRE - мол можно писать только на позитивные кейсы если инцедентов нет. Если они есть - увеличиваете количество. Бюджет появился - можно опять не писать и быстрее фичи в прод лить.

ну а e2e - у них есть обоснование как "внешнее качество" и у них есть вполне конкретная стоимость которую можно померять

если мы пилим какой-нибудь инстаграм - 90% всего приложения можно будет покрыть за счет e2e и интеграционных тестов и в целом причин по которым мы захотим юзать юниты не сильно много. Оставшиеся 10% - там вот может быть чет и будет. У кого-то проекты другие и там распределение будет другим.

Конечно удобнее читать всякие "а вот в гугле 80% кавередж" и считать что ты хочешь "как средний по больнице проект в гугле" делать

p.s. в целом мне лично больше нравится in-process тестирование как термин - он куда более емкий и лучше описывает некоторые ограничения полезные для команд разработки.

Еще не слышал об этом понятии. Схоронил на будущее.

Некропост, но и это сейчас решается всякими амплитудами и google tracking events.

А если реально, возможен ли юзкейс где как раз нужен просто молниеносный рантайм? Что делать если тебе критичен молниеносный рантайм + это распред система. Как синхронизировать?