Привет

А подскажите пожалуйста чем осенью 2012 года модно тестировать логику в хранимых процедурах? Сейчас процедур около десятка, планируется намного больше. Хочется иметь возможность:
1. Описывать контракт в виде тестов.
2. Иметь возможность автоматически делать регрессионное тестирование.
3. В идеале — TDD

Процедуры на T-SQL, база на SQL Server 2008.

On 09/08/2012 09:47 PM, andyag wrote:

> А подскажите пожалуйста чем осенью 2012 года модно тестировать логику в хранимых
> процедурах? Сейчас процедур около десятка, планируется намного больше. Хочется
> иметь возможность:
> 1. Описывать контракт в виде тестов.
> 2. Иметь возможность автоматически делать регрессионное тестирование.
> 3. В идеале — TDD

Я не знаю, чем модно, могу предложить рабочую схему, даже две.

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

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

fitnesse + dbfit. Далеко не идеал, но лучшего ничего пока не нашли.

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

A>Привет

A>А подскажите пожалуйста чем осенью 2012 года модно тестировать логику в хранимых процедурах? Сейчас процедур около десятка, планируется намного больше. Хочется иметь возможность:
A>1. Описывать контракт в виде тестов.
A>2. Иметь возможность автоматически делать регрессионное тестирование.
A>3. В идеале — TDD

A>Процедуры на T-SQL, база на SQL Server 2008.

Для .net есть прекрасные продукты, nCrunch (за $), nSubstitute и FluentAssertions. Для веб приложений еще Selenium есть.

Проверено на личном опыте на нескольких проектах. Тесты для функционала, если оный криво написан предшественником и ты выгребаешь проект из пепла, могут быть надоедливо медленные, несколько секунд могут занимать и ТДД становиться мукой и недопустимо медленным. Но обвинить эту связку в этом будет трудно так как с алгоритмами все замечательно, 5-10 тестов в секунду.

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

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

A>>Привет

A>>А подскажите пожалуйста чем осенью 2012 года модно тестировать логику в хранимых процедурах? Сейчас процедур около десятка, планируется намного больше. Хочется иметь возможность:
A>>1. Описывать контракт в виде тестов.
A>>2. Иметь возможность автоматически делать регрессионное тестирование.
A>>3. В идеале — TDD

A>>Процедуры на T-SQL, база на SQL Server 2008.

PP>Для .net есть прекрасные продукты, nCrunch (за $), nSubstitute и FluentAssertions. Для веб приложений еще Selenium есть.

Selenium научился тестировать хранимки?

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

A>Привет

A>А подскажите пожалуйста чем осенью 2012 года модно тестировать логику в хранимых процедурах? Сейчас процедур около десятка, планируется намного больше. Хочется иметь возможность:

Логику в хранимках в тестировать в общем случае практически невозможно. Я в конечном итоге пришел к тому, что если очень надо что-то тестировать — это надо оформлять как UDF

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

MZ>On 09/08/2012 09:47 PM, andyag wrote:

>> А подскажите пожалуйста чем осенью 2012 года модно тестировать логику в хранимых
>> процедурах? Сейчас процедур около десятка, планируется намного больше. Хочется
>> иметь возможность:
>> 1. Описывать контракт в виде тестов.
>> 2. Иметь возможность автоматически делать регрессионное тестирование.
>> 3. В идеале — TDD

MZ>Я не знаю, чем модно, могу предложить рабочую схему, даже две.

MZ>Пишешь свою консольку (программу консольную для выполнения запросов
MZ>и получения результатов) и в ней реализуеш макросы для проверки
MZ>резульаттов выполнения запросов, на них строиш тестовые скрипты.

к примеру есть функция получающая сумму продаж по клиентам Сахалинской области
Какого плана должны быть тесты?
Насколько я вижу первый тест: клиенты Сахалинской области.
Если нет такой функции(в процедуре идет джойн на таблицу), то получается под тест надо отдельно писать функцию?