Ты все повторяешь эти мантры, но на свой простенький пример я так и не получил никакого внятного предложения. Чтоб без доступа к private методам, да еще и удобно.

Какая разница декларативен он или нет? Я в SQL много багов встречаю как минимум потому что мы не все про данные знаем/помним, какие-то моменты забываются и опа - миграция свалилась. Или того хуже - прошла, но неверно. Плюс бывает не по той ветке join'ов пошли и собрали не те данные.
maytonКроме того инструмент тестирования должен быть проще объекта тестирования. Иначе возникает
другой парадокс о правильности самого инструмента и его statement. Или надо писать тест на тест.Не знаю откуда такие требования взялись. Как инструмент для тестирования, так и сами тесты могут быть значительно сложней основного кода. И сил нужно будет потратить на тестирование намного больше чем на написание прод кода.

Все зависит от того сколько гарантий мы хотим получить, насколько важно чтоб код работал верно. Если мы пишем какое-то второстепенное ПО для банка - народ переживет даже если оно совсем работать не будет. А если это софт для управления самолетами, ракетами, АЭС - то тут же совсем другой разговор. Тут и PBT, и MBT, и чего только не прийдется использовать. И конечно же сами инструменты для тестирования должны быть протестированы.

Ну из своего проекта я конечно приводить примеров не буду, ну вот что-то подобное, синтезированное:
1. Решили для упрощения бизнес логики явно писать в БД имеет ли пользователь доступ к объекту или нет (вместо того чтоб вычислять на лету). Написали миграцию, которая проставляет флаг=true если пользователю >18. Но оказалось, что есть исключение - страна, в которой доступ можно разрешать только с 16. И админам (у которых возраст может быть не указан) тоже разрешать.
2. Добавляем новую колонку, знаем что она not null. Сразу же проставили constraint (а след строкой заполняем данными), хотя в таблице есть строки.
3. ... и т.д.

maytonИ мне также интересно как вы подготавливаете данные для подобного тестирования?Мы редко пишем на это тесты. Но если пишем - ну заполняем данными, затем запускаем миграцию, затем проверяем результат. Это больше для background миграций, которые идут длительное время. Для таких приложение должно поддерживать и старые, и новые данные.

А так.. как правило у нас есть дамп с прода - на нем куа тестируют вручную. Проходятся по своей тестовой документации, вспоминают что могли упустить, анализируют результат.
maytonНо вы не можете доказать теорему Пифагора через Теорему Косинусов. Это абсурд. Никто не примет такое
доказательство.Во-первых, в математике бывает что доказывают/высчитывают что-то более простое какими-то более сложными (я счас не говорю про цикличность) абстракциями. Типа посчитать площадь четырехугольника с помощью cross product'a двух векторов. А во-вторых, мы про доказательства (где цикличность нежелательна) ничего не говорили - мы говорим про протестировать . А тут уж крути-верти как хочешь, твоя задача просто написать два куска кода результат которых будет совпадать.

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

Другой пример (более реалистичный) - test oracle. Хотим какую-то структуру данных реализовать. Более простую чем что-то существующее в Java SDK, с меньшим функционалом, но быстрей. Как мы ее будем тестировать? Можем написать MBT с использованием стандартной реализации в качестве модели. И получается тестируем более простой код более сложным.

Третий пример (еще реалистичней) - написали какую-то concurrent структуру данных. И вот тут попробуй еще написать тесты которые бы выявили многопоточные проблемы..