тесты для БД

Когда пользовался ораклом, в ихнем скульдевелопере были тулзы для юниттестирования. Хз можно ли их гонять отдельно, т.к. ими мы не пользовались, а тесты по выборкам и т.п. запускали на уровне приложения.

тесты по выборкам и т.п. запускали на уровне приложения.

у меня по большому счету нет приложения, у меня все на хранимках. «приложения» даже интерфейс генерит из них.

У меня никогда то такого не доходило, только в рамках оптимизаций. Попробуй поковырять тут https://docs.oracle.com/cd/E15846_01/doc.21/e15222/unit_testing.htm#RPTUG45000

я там был, но я все еще никак не могу придумать как же это применить... и howto чета не видать рядом.

как уловить этот момент? контрольный, эдакий const-селект я сделать не могу, у меня элементарно таблички меняются.

запили тестовый набор данных, который будет инсертиться в пустую таблицу, на нём и проверяй

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах (файлах).

2. Храни sql скрипты в системе контроля версий. Объяви sql скрипты официальным местом хранения исходников серверной части, а всё, что занесено в базу напрямую DDL запросами - это фигня, пока его нет в скриптах.

3. Сделай систему патчей, которая управляет модификацией метаданных. В патчи заноси все DDL запросы, модифицирующие структуру таблиц, а также все DML запросы, которые производятся при апгрейде базы. Модифицируй все свои базы только через систему патчей. Для хранимых процедур и триггеров это обычно не нужно - ты хранишь не дельту состояния, а последнее состояние (пп 1-2). Хотя бывают всякие случаи.

4. Имей инструмент, выдающий дампы двух баз и сравнивающий эти дампы почленно. В простейшем случае - выдать дамп каждого объекта по алфавиту и потом гуишный diff.

5. Поддерживай тестовую базу с неизменными данными. Имея пп 1,2,3 - не трудно будет модифицировать её структуру по ходу развития промышленной базы. На самом деле у тебя будет не менее 3 баз, если ты работаешь один: разработческая, тестовая и боевая. Если ты работаешь не один, то баз может быть значительно больше. И все их можно поддерживать с помощью п.п.1,2,3.

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

6. Тестируй на этой самой выделенной тестовой базе. Если ты сделаешь её из промышленной, у тебя сразу же будет возможность тестировать и производительность, что не менее важно, чем тестирование правильности запросов.

У меня руки так и не дошли до создания системы автотестов, потому что последняя разработанная мной система недостаточно долго прожила в промышленной эксплуатации. Ну и плюс лень и нерадение. Но если бы я стал делать автотесты для БД, то сделал бы именно так.

пп 1-4 я реализовал (для MSSQL и для Firebird).

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.