Зачем нужны фейковые данные для тестирования?

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

До сих пор не могу понять, почему классы надо тестировать, а данные не надо.
Точнее я понимаю, что для простой программы где данные являются пассивными по отношению к структуре программы, возможно, их тестировать и не надо.

Но как быть если данные которые создаются пользователем в рабочей базе данных влияют на структуру программы, например, в некоторых CMS в базе храниться почти всё, что касается программы (сайта).

У меня примерно похожая ситуация — то, что пользователь создаёт в базе, непосредственно влияет на всю программу и часто является источником сложноуловимых ошибок.

Собственно говоря, я, не обращая внимание, на повсеместное создание фейковых данных во всех учебниках по тестированию, стал его игнорировать и прямолинейно использую реальные данные из базы в юнит тестах.

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

Не приводит ли это к логическому противоречию? Мы тестируем всегда валидные хранилища и классы.
При этом если логика программы влияет на порядок создания, хранения в куче и удаление объектов то мы никогда ошибок не найдём.

То же касается и ошибок данных которые могут влиять на бизнес-логику.

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

Простой, вырожденный пример — Юзер пишет в карзину Яблоко — 100 кг по 1 грн, а в это время Администратор меняет условие скидок — за каждый килограмм более 10 — минус 1.5 грн. расчитывая что в розницу никто больше двух килограмм не купит. В результате минус в сумме.

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

Может быть есть какая-то область знаний типа Тестирование данных о которой я не знаю?

Кто-то с чем то подобным сталкивался? Куда копать?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті