Здравствуйте, Sshur, Вы писали:

S>ну давай назовем это тестом совместимости БД и ПО
И чем это отличается от обычных unit-тестов этого же ПО ?

S>Код на всем чего хочвешь, это интересно — а как?

Хотя бы так

S>Это слишком муторно делать и поэтому у разработчика велик соблазн не писать тест для процедуры. Да и по времени очень напряжно, вероятность ошибки велика.

Не надо так говорить — эти же отмазки я слышал и про unit-тесты
Все зависит от архитектуры — разве об этом не говорилось в вашем же посте?
ИМХО, unit-тесты дают ошутимую выгоду лишь при определенных условиях. Важнейшим из условий является разделение интерфейса и реализации в коде — в СУБД с этим проблемы, кроме случая постоянного переписывания одних и тех же процедур не изменяя их сигнатуры.

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

Здравствуйте, Sshur, Вы писали:

S>Это слишком муторно делать и поэтому у разработчика велик соблазн не писать тест для процедуры. Да и по времени очень напряжно, вероятность ошибки велика.

Ну не могу спокойно воспринять эти слова
Unit-тесты и функциональные тесты тоже муторно делать и соблазн также велик, если не еще выше. И по времени — покрыть все классы приложения тестами — чуть не вдвое больше времени уходит на кодирование.
Как только сложность проекта возрастет — тесты неизбежны


Кстати, сложность хранимых процедур тоже может свидетельствовать об ошибках проектирования структуры БД или приложения.

Здравствуйте, kavlad, Вы писали:



K>И главное — обычно ведь происходит тонкая настройка БД для оптимизации производительности, даже ее архитектура у более-менее грамотного проектирвщика обязательно затачивается под производительность. А перделка под удобное тестирование скорее всего разрушит эту оптимизацию.
K>И вторым процессором здесь врядли спасешься. Но об этом уже говорили другие.


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


А вообще эти слова — про то, что надо затачивать под производительность и прочее — напоминают слова низкоуровневого программиста о преимуществах ассемблера перед java или C# — никто не спорит, что java медленне, но ведь сложные проекты на ассемблере не пишут, и покупают для работы сейчас копьютеры, способные на C# выполнять те же задачи, что и 486 на ассемблере. Только стоимость разработки сейчас ниже и сложность программ такая, что не снилась во времена процедурного программирования.
Поэтому заточка под производительность рано или поздно уйдет в сторону перед удобством проектирования и тестирования.
К тому же мне кажеться, что возможно совмещать и то, и то — по крайней мере на уровне компромисса Пусть в 2 раза медленнее считает, зато ошибок не так много

Здравствуйте, Sshur, Вы писали:

S>А вообще эти слова — про то, что надо затачивать под производительность и прочее — напоминают слова низкоуровневого программиста о преимуществах ассемблера перед java или C#

ИМХО, не надо путать божий дар с яичницей Произошел качественный скачек в развитии железа — поэтому стало возможным ослабить требования к производительности, оптимизации кода в ряде задач. СУБД все еще остаются "тяжеловесными" задачами, требующими тонкой настройки.

S>Поэтому заточка под производительность рано или поздно уйдет в сторону перед удобством проектирования и тестирования.

Возможно. Очень даже. Но... Работа с БД очень часто является критическим местом приложения, здесь часто скрыты затыки производительности.


По первому посту у меня сложилось впечатление, что есть достаточно сложные процедуры, которые трудно проверить ручками.
TTD как раз и приучает к тому, что код должен быть простым, иначе его сложно тестировать
Я уже говорил, что может быть стоит посмотреть на архитектуру БД — разбить сложную процедуру на несколько простых, хранить промежуточные результаты и т.п.

S>К тому же мне кажеться, что возможно совмещать и то, и то — по крайней мере на уровне компромисса Пусть в 2 раза медленнее считает, зато ошибок не так много

Не все задачи могут перенести такое падение производительности. А БД имеют свойство разрастаться
Вам захочется пользоваться гуглом, если он будет искать в два раза медленнее
И еще хорошо, если в два

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

Хотелось бы узнать подробнее, как вы видите себе такой инструмент.