это как срачи "что лучше мокисткая школа TDD или класицисты" которую устраивают люди которые тесты пишут после и думаю о тестировании когда уже все сделано и потестили руками (в IDE с дебагером)

shift left все дела... вот про эти штуки надо думать. Понятно что это сложно, думать надо, а потому лучше пустые срачи затевать. Это как ООП vs FP

тестер который не знает о реализации не может делать никаких допущений которые позволяют ему уменьшить количество тест кейсов. Это либо будет приводить к колосальной стоимости разработки (потому и кричат что тесты дорого) либо ты просто будешь выбирать только подмножество ситуаций.

у меня вот под рукой пример есть - есть фича - ресет пароля. Вроде фича простая, есть email, юзер хочет себе пароль сбросить, чеб не разрешить.

Но дальше начинаются веселые вещи. Кто-то подумал "а давайте мы будем еще проверять может ли он это с этого скрина делать" (для упрощения) а вообще все ли роли могут это делать и еще куча всего. И вжух на простую фичу которая покрывалась бы 3-мя тест кейсами (можно, нет такого, заблокировано) я вижу 16 тест кейсов и кучу зависимостей. Оправданы ли эти зависимости для этой фичи? нет.

тестер который не знает реализации будет надеяться что у тебя внутреннее качество норм и эффекты системы на элементы контролируются. Потому и нужны все эти юнит тесты, компонентные тесты, контрактрые тесты - что бы форсить внутреннее качество и изолировать влияние.

ну а на тему того что "разработчик херовые тест кейсы пишет" - пишите тест кейсы ДО реализации и все будет хорошо

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

дай определение белому ящику

потому что даже в мокистской школе TDD "белый ящик" это антипаттерн) хотя казалось бы

все тесты "завязаны" на реализацию, есть тесты которые реализацию дублируют. Это когда у тебя например тест проверяет какие методы и в каком порядке ты вызывал - такие тесты можно просто удалить так как они не приносят пользы и могут создавать иллюзию безопасности.

есть ситуация когда тебе надо проверить сайд эффекты - например уходят ли sms-ки. Юзаешь ли ты для этого моки в юнит тестах, фэйковую имплементацию и ассерты в массивчике, сервис-заглушку или сэндбокс сервис провайдера - фактически все это суть одного и того же

Своими словами? Тестирование системы/модуля в условиях доступности и анализа исходного кода с возможным (но не обязатеным) построением тестов относительно конкретных выражений/переходов реализации.

ну то есть когда есть отдельные автоматизаторы которые пишут e2e через силениумы/апиумы/хуяпиумы - тогда у нас черный ящик

какую такую интересно теорию ты читал

Ну да, согласен. Могу лишь дополнить, что лично я его применение считаю допустимым в условиях наличия тестов по черному ящику. Как дополнение, а не замена.

нет никаких белых ящиков, я к этому веду

есть дублирование реализации в тестах - это вот проблема

Нет, я не имел ввиду подобное к проверке вызова методов и их очередности. Речь скорее о прекондишенах и построению тестов относительно их просмотра в коде

у "лондонской школы TDD" со всей их любовью к mock frameworks и т.д. такой проблемы нет по одной простой причине - они стабы и моки юзают для проектирования зависимостей, top-to-bottom декомпозиция.

Проблемы с этим всем возникают у людей которые сначала нахуячат заюзав "Общие" интерфейсы и не озоботившись проверкой контрактов обмазываются моками