Здравствуйте,
Поделитесь пожалуйста наиболее эффективным подходом к тестированию, когда тесты используют базу данных. Т.е. либо юнит-тесты выполнения хранимой процедуры/функции (выполнили ХП, проверили что она вернула или изменила в базе), либо интеграционные/функциональные (я в терминологии не силен) тесты включающие работу с БД.
Например 2 последних реальных примера:
1) Нетривиальная ХП на страничку sql-кода. Нужно ее вызвать и проверить что она правильно изменила БД.
2) Функция генерации прайс-листов. Нужно ее вызвать а потом открыть сгенерированный эксель файл и проверить что там верные данные. (это я так понимаю интеграционный тест? или функциональный?).

Основных варианта я вижу два:
1) Использование копии реальной базы данных (копии, а не просто схемы без данных, потому что в копии реальной БД зачастую уже есть данные которые можно для теста использовать), в коде теста добавлять в базу нужные для теста данные. И вот это есть геморрой. Иногда подготовка данных занимает 1-2 страницы кода. И это лишь для 1 теста. (Честно говоря иногда даже тест писать не охото, потому что понимаю что займет не очень мало времени, либо этого времени просто нет, т.е. есть более приоритетные задачи).
2) Поддержка специальной БД для тестов. Её можно хорошо подготовить 1 раз, так что она будет подходить для многих тестов. А если для какого-то теста нужно будет добавить еще данных, то это можно сделать в любимом SQL-редакторе, что может быть быстрее чем писать страницу или две кода, подготавливающего БД для теста. Минус тут в том что надо синхронизировать структуру этой базы данных с реальной базой данных. Т.е. если мы в реальной БД добавили колонку, то и в тестовой надо будет тоже добавить не забыть.

Еще можно стараться тесты сделать так, чтобы они не зависели от конкретных данных в БД (иногда это удается, особенно если использовать копию реальной БД, но далеко не всегда), тогда можно избежать фазы подготовки БД к тесту.

Может быть я вообще не то говорю и все может быть проще и правильнее? Что скажете? Если есть ХОРОШИЕ ссылки конкретно по моему вопросу — будет полезно.
Заранее спасибо.

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

MC>2) Поддержка специальной БД для тестов. Её можно хорошо подготовить 1 раз, так что она будет подходить для многих тестов. А если для какого-то теста нужно будет добавить еще данных, то это можно сделать в любимом SQL-редакторе, что может быть быстрее чем писать страницу или две кода, подготавливающего БД для теста. Минус тут в том что надо синхронизировать структуру этой базы данных с реальной базой данных. Т.е. если мы в реальной БД добавили колонку, то и в тестовой надо будет тоже добавить не забыть.

Вот это подойдет.

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

В реальном мире, конечно, все зависит от того, что дешевле и эффективнее — подставить сервису тестовую БД или экспериментировать на обычной базе.

Я пару раз наступал на такие проблемы.
ИМХО самы прямой путь — иметь в проекте файлик вроде SetupDb.sql. База
данных создаваемая этим файлом и есть эталонная схема БД (для заданной
версии проекта). В дальнейшем для тестов использующих БД использовать
базовый класс тесткейза в котором в setUp и tearDown создается (и
удаляется) БД на основе файла SetupDb.sql. В самом тесте в setUp может
использоваться другой SQL файл с данными чтобы заполнить БД тестовыми
данными.

Часто бывает так, что в проекте у базы данных нет скрипта для ее
создания. Схема правится вручную, или есть масса мелких скриптов. В этом
случае создавать базу для каждого теста проблемматично. Я пользовался
инициацией и откатом транзакции в setUp tearDown. Подход работает, но
тесты не могут опираться на какой-нибудь устойчивый набор данных. Т.к. в
базе постоянно происходят изменения.

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

MC>Здравствуйте,


MC>Может быть я вообще не то говорю и все может быть проще и правильнее? Что скажете? Если есть ХОРОШИЕ ссылки конкретно по моему вопросу — будет полезно.
MC>Заранее спасибо.


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

Но, кроме трудоемкости, меня в этом подходе смущают два обстоятельства. Во-первых, мы во многом теститируем базовый функционал sql сервера, то есть способность правильно делать insert и select. Оно нам надо? А во-вторых, мы тем самым накапливаем себе на будущее проблемы изменения тестового либо эталонного набора данных при изменении логики. То есть рано или поздно мы скажем — а оно стоит того, вносить эти изменения, ведь для этого надо поменять чертову кучу тестовых скриптов?

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

Касательно ваших примеров

1) Нетривиальная ХП на страничку sql-кода. Нужно ее вызвать и проверить что она правильно изменила БД.

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

declare @var1 int
declare @var2 int
...
declare @varN int


select @var1 = value1 from table1
select @var2 = value2 from table2
..
select @varN = valueN from table3

declare @out_var1 int 


select @out_var1 = dbo.my_calc_function(@var1,@var2, ..., @varN)

insert into out_table (out_value) values( @out_var1)

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

Соответственно, тестировать теперь надо только my_calс_function, так как основная масса изменений будет вноситься именно туда.

2) Функция генерации прайс-листов. Нужно ее вызвать а потом открыть сгенерированный эксель файл и проверить что там верные данные. (это я так понимаю интеграционный тест? или функциональный?).

Это ИМХО функциональный тест. С одной стороны, то что я предлагаю делать — это UNIT тестирование, функциональные тесты оно полностью не заменит. Но, исходя из идеологии unit тестов, оно и не должно его заменять. Unit тесты делаются разработчиком автоматизированно практически постоянно, а функциональные тесты вполне могут делаться вручную тестерами перед релизом или его аналогом. А использование Unit тестов и в данном случае значительно уменьшит объем необходимого функционального тестирования.
Если разобрать процедуру генерации прайс листа из БД в xls, то она явно должна содержать несколько этапов, как минимум этап расчета цены и этап выгрузки данных в Excel. Первое вполне поддается unit тестированию в БД (см. пункт 1), а второе — вроде бы вообще к БД не относится, и скорее всего тоже может быть протестировано, только другими средствами.
Получается, что тестирование этапов по отдельности легко автоматизируется, а вместе — нет. Тогда возникает такой вопрос — а нужно автоматически все тестировать? Насколько часто переписывается процедура расчета цены и насколько часто переписывается процедура экспорта в Excel? Я уверен, что экспорт в эксель используется какой-то внешний и готовый, его написали один раз и забыли, а вот расчет стоимости в соответствии с изменениями бизнеса меняется постоянно. Ну так и стоит ли тестировать то, что не изменяется? Задумайтесь

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

Уточни, что именно ты хочешь тестировать — код работы с БД, то есть DB-layer, или сами ХП?

Есть такая точка зрения, что логика, реализованная внутри БД (ХП, запросы, view), должна тестироваться независимо от приложения. Возможно, с помощью своего фреймворка, работающего в той же БД.

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

В свое время я пробовал работать с реальной базой данных, но каждый раз, когда в ней менялась структура или данные, половина тестов падала. Поэтому я бы посоветовал создавать базу каждый раз в [FixtureSetup]. Но только структуру, а данные все-таки запариться и создавать в тестах. Если разные тесты используют одни и теже данные, вынести в общий код. Вообще-то необходимо вынести код, наполняющий тестовую базу данными, в отдельное место, чтобы не мешать его с собственно самими тестами. Причина в том, что, посмотрев на тест, ты должен понять, что он проверяет. А если будут готовые данные в базе, то придется лезть в базу.

Псевдокод:
[FixtureSetup] public void ...
DbUtils.CreateSchema();
DbUtils.AddOrderRecord(...);
...

[Test] public void ..
DbUtils.RunSProc("MySproc", param1, ...);
DbUtils.AssertRecordCount(5, "Orders", "CustomerId=8");
DbUtils.AssertRecordExists("Orders", "Id=2");
и т.д.

Какое-то время уйдет на написание кучи утилит, но это все окупится. В частности, тесты становятся понятными, и не надо каждый раз по три часа выяснять, почему что-то сломалось. Каждый раз, когда тест писать "неохота", это знак, что пора написать очередную утилиту, чтобы стало все проще.

Если же надумаете отказаться от ХП, в тестах можно будет использовать SQLite -- и создавать in-memory database, что работает гораздо быстрее.

ulu

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

MC>Здравствуйте,
MC>Поделитесь пожалуйста наиболее эффективным подходом к тестированию, когда тесты используют базу данных. Т.е. либо юнит-тесты выполнения хранимой процедуры/функции (выполнили ХП, проверили что она вернула или изменила в базе), либо интеграционные/функциональные (я в терминологии не силен) тесты включающие работу с БД.
MC>Например 2 последних реальных примера:
MC>1) Нетривиальная ХП на страничку sql-кода. Нужно ее вызвать и проверить что она правильно изменила БД.
MC>2) Функция генерации прайс-листов. Нужно ее вызвать а потом открыть сгенерированный эксель файл и проверить что там верные данные. (это я так понимаю интеграционный тест? или функциональный?).

MC>Основных варианта я вижу два:
MC>1) Использование копии реальной базы данных (копии, а не просто схемы без данных, потому что в копии реальной БД зачастую уже есть данные которые можно для теста использовать), в коде теста добавлять в базу нужные для теста данные. И вот это есть геморрой. Иногда подготовка данных занимает 1-2 страницы кода. И это лишь для 1 теста. (Честно говоря иногда даже тест писать не охото, потому что понимаю что займет не очень мало времени, либо этого времени просто нет, т.е. есть более приоритетные задачи).
MC>2) Поддержка специальной БД для тестов. Её можно хорошо подготовить 1 раз, так что она будет подходить для многих тестов. А если для какого-то теста нужно будет добавить еще данных, то это можно сделать в любимом SQL-редакторе, что может быть быстрее чем писать страницу или две кода, подготавливающего БД для теста. Минус тут в том что надо синхронизировать структуру этой базы данных с реальной базой данных. Т.е. если мы в реальной БД добавили колонку, то и в тестовой надо будет тоже добавить не забыть.

MC>Еще можно стараться тесты сделать так, чтобы они не зависели от конкретных данных в БД (иногда это удается, особенно если использовать копию реальной БД, но далеко не всегда), тогда можно избежать фазы подготовки БД к тесту.

MC>Может быть я вообще не то говорю и все может быть проще и правильнее? Что скажете? Если есть ХОРОШИЕ ссылки конкретно по моему вопросу — будет полезно.
MC>Заранее спасибо.

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

MC>>2) Поддержка специальной БД для тестов. Её можно хорошо подготовить 1 раз, так что она будет подходить для многих тестов. А если для какого-то теста нужно будет добавить еще данных, то это можно сделать в любимом SQL-редакторе, что может быть быстрее чем писать страницу или две кода, подготавливающего БД для теста. Минус тут в том что надо синхронизировать структуру этой базы данных с реальной базой данных. Т.е. если мы в реальной БД добавили колонку, то и в тестовой надо будет тоже добавить не забыть.

R>Вот это подойдет.
R>Тесты должны быть в первую очередь предсказуемыми. Лучшим обеспечением этого является заранее заготовленная БД.

Как решается проблема с синхронизацией изменений схемы в тестовой БД? Как это не забывать делать?

R>В реальном мире, конечно, все зависит от того, что дешевле и эффективнее — подставить сервису тестовую БД или экспериментировать на обычной базе.
Ага, ну как я уже написал выше, в случае с реальной БД — геморойно в тесте данные подготавливать. А в случае с тестовой БД данные можно подготовить и в любимом SQL редакторе, но потом нужно не забывать синхронизировать схему тестовой БД со схемой реальной БД.

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

OS>Я пару раз наступал на такие проблемы.
OS>ИМХО самы прямой путь — иметь в проекте файлик вроде SetupDb.sql. База
OS>данных создаваемая этим файлом и есть эталонная схема БД (для заданной
OS>версии проекта). В дальнейшем для тестов использующих БД использовать
OS>базовый класс тесткейза в котором в setUp и tearDown создается (и
OS>удаляется) БД на основе файла SetupDb.sql. В самом тесте в setUp может
OS>использоваться другой SQL файл с данными чтобы заполнить БД тестовыми
OS>данными.

Но я как раз написал, что в этом случае подготовка тестовых данных может быть геморойной, в этом и проблема для меня. Мне вот например сейчас чтобы протестировать работу ХП нужно тестовых данных добавить, что займет 1-2 страницы кода.

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

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

R>>Тесты должны быть в первую очередь предсказуемыми. Лучшим обеспечением этого является заранее заготовленная БД.

MC>Как решается проблема с синхронизацией изменений схемы в тестовой БД? Как это не забывать делать?

Если существует код, ответственный за создание и обновление БД до последней версии, и если этот код вызывается перед тестами на тестовой БД, то оно само.
Т.е. сценарий следующий: изменяется разработческая БД, готовятся скрипты для обновления существующих БД, эти скрипты выполняются над тестовой БД (можно и в режиме тестов), после этого все готово к обновлению реальных БД.

R>>В реальном мире, конечно, все зависит от того, что дешевле и эффективнее — подставить сервису тестовую БД или экспериментировать на обычной базе.
MC>Ага, ну как я уже написал выше, в случае с реальной БД — геморойно в тесте данные подготавливать. А в случае с тестовой БД данные можно подготовить и в любимом SQL редакторе, но потом нужно не забывать синхронизировать схему тестовой БД со схемой реальной БД.

Схема таким образом сама синхронизируется, но все Insert-ы, используемые при наполнении тестовых данных придется править руками, если они в SQL виде.

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

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

W>Уточни, что именно ты хочешь тестировать — код работы с БД, то есть DB-layer, или сами ХП?
По разному. Иногда мне нужно проверить что ХП отработала так как должна. Т.е. нужно ее вызвать и проверить как изменились данные в БД. Иногда я хочу сделать общий тест (как уже писал интеграционный или функциональный, не очень понимаю разницу), я хочу вызвать процедуру генерации прайс листа, а потом открыть результирующий excel файл и проверить его.

W>Есть такая точка зрения, что логика, реализованная внутри БД (ХП, запросы, view), должна тестироваться независимо от приложения. Возможно, с помощью своего фреймворка, работающего в той же БД.
А подробнее можно мысль развить? И опять же, что если хочется сделать функциональный/интеграционный тест.

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

ulu>Обычно имеет смысл прислушиваться (некоторые говорят, принюхиваться) к тестам, и если они становятся громоздкими и неудобочитаемыми, это намек на то, что пора бы уже менять дизайн приложения (в частности, отказаться от ХП
Какая разница где будут запросы. Сейчас допустим они в ХП, а станут в DAL в виде db.ExecuteNonQuery("bla blb bla") — все равно я захочу проверить что функция в DAL выполнилась корректно и привела к ожидаемому изменения базы данных или вернула ожидаемый результат.

ulu> Но работа с базой -- дело другое.
ulu>В свое время я пробовал работать с реальной базой данных, но каждый раз, когда в ней менялась структура или данные, половина тестов падала. Поэтому я бы посоветовал создавать базу каждый раз в [FixtureSetup]. Но только структуру, а данные все-таки запариться и создавать в тестах.
Я вообще-то как раз от этого и хочу избавиться. Мне сейчас чтобы протестировать 1 ХП нужно тест на 2-3 страницы написать, потому что большая часть будет подготовка данных.

ulu>Если разные тесты используют одни и теже данные, вынести в общий код. Вообще-то необходимо вынести код, наполняющий тестовую базу данными, в отдельное место, чтобы не мешать его с собственно самими тестами. Причина в том, что, посмотрев на тест, ты должен понять, что он проверяет. А если будут готовые данные в базе, то придется лезть в базу.
А зачем мне смотреть на тест? Я его один раз написал и забыл. Если он вдруг упадет через 2 года, ну что ж — залезу в базу и гляну.

ulu>Псевдокод:
ulu>[FixtureSetup] public void ...
ulu> DbUtils.CreateSchema();
ulu> DbUtils.AddOrderRecord(...);
ulu> ...

ulu>[Test] public void ..
ulu> DbUtils.RunSProc("MySproc", param1, ...);
ulu> DbUtils.AssertRecordCount(5, "Orders", "CustomerId=8");
ulu> DbUtils.AssertRecordExists("Orders", "Id=2");
ulu>и т.д.

Выглядит неплохо, но, как я уже много раз писал, иногда код по подготовке тестовых данных занимает 2 страницы кода и даже из-за этого не хочется тест писать. Вот это и хочется как-то упростить, сделать удобнее. Либо вообще подойти с какой-то другой стороны.

Кстати с копией реальной БД удобно тем, что нередко в базе уже есть данные по которым можно тест написать.

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

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

MC>Я вообще-то как раз от этого и хочу избавиться. Мне сейчас чтобы протестировать 1 ХП нужно тест на 2-3 страницы написать, потому что большая часть будет подготовка данных.

См. рецепт упрощения работы ниже. Если грамотно запариться, то потом все будет просто.

MC>А зачем мне смотреть на тест? Я его один раз написал и забыл. Если он вдруг упадет через 2 года, ну что ж — залезу в базу и гляну.

Если приложение будет активно развиваться, то вполне вероятно, что тесты будут время от времени падать. И понадобится срочно понять, что тут происходит. А через два года, чтобы во всем этом разобраться, уйдет гораздо больше времени, чем написать приличный и понятный тест.

ulu>>Псевдокод:
ulu>>[FixtureSetup] public void ...
ulu>> DbUtils.CreateSchema();
ulu>> DbUtils.AddOrderRecord(...);
ulu>> ...

ulu>>[Test] public void ..
ulu>> DbUtils.RunSProc("MySproc", param1, ...);
ulu>> DbUtils.AssertRecordCount(5, "Orders", "CustomerId=8");
ulu>> DbUtils.AssertRecordExists("Orders", "Id=2");
ulu>>и т.д.

MC>Выглядит неплохо, но, как я уже много раз писал, иногда код по подготовке тестовых данных занимает 2 страницы кода и даже из-за этого не хочется тест писать. Вот это и хочется как-то упростить, сделать удобнее. Либо вообще подойти с какой-то другой стороны.

Что, даже со всеми упрощениями? В моем псевдокоде каждой записи в базе соответствует одна строчка. Сколько же данных надо вбивать в базу для теста? Может, Ваша хранимка делает слишком много? Если не секрет, что это за тест такой, что надо 50 записей готовить? Или это 50 таблиц, в каждую по записи?

MC>Кстати с копией реальной БД удобно тем, что нередко в базе уже есть данные по которым можно тест написать.

Я, по природе, человек очень ленивый. И писать лишний код мне всегда влом. Поэтому я тоже старался пользоваться уже готовыми данными. Но это повернулось против меня, как я уже писал.

Возьмите базу с готовыми данными, сделайте скрипт, который вставляет в базу эти данные, и пользуйтесь им при создании тестовой базы. У Вас будет вполне предсказуемая тестовая база (взамен непредсказуемой реальной), и не придется данные вставлять в коде.

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

MC>>Я вообще-то как раз от этого и хочу избавиться. Мне сейчас чтобы протестировать 1 ХП нужно тест на 2-3 страницы написать, потому что большая часть будет подготовка данных.
ulu>См. рецепт упрощения работы ниже. Если грамотно запариться, то потом все будет просто.
А у вас класс DbUtils на что завязан? Я к тому что можно ли было бы мне его заиметь и подделать под мой MySql.

MC>>А зачем мне смотреть на тест? Я его один раз написал и забыл. Если он вдруг упадет через 2 года, ну что ж — залезу в базу и гляну.
ulu>Если приложение будет активно развиваться, то вполне вероятно, что тесты будут время от времени падать.
У меня приложение активно развивается, а тесты редко падают.. Может я супер крут? Или мало тестов и они слабые?..

ulu>И понадобится срочно понять, что тут происходит. А через два года, чтобы во всем этом разобраться, уйдет гораздо больше времени, чем написать приличный и понятный тест.
Это да, недавно как раз большой тест упал, полчаса убил чтобы вникнуть как работает эта мешанина, которую я написал год назад . Но опять же, такое бывает очень редко...

MC>>Выглядит неплохо, но, как я уже много раз писал, иногда код по подготовке тестовых данных занимает 2 страницы кода и даже из-за этого не хочется тест писать. Вот это и хочется как-то упростить, сделать удобнее. Либо вообще подойти с какой-то другой стороны.

ulu>Что, даже со всеми упрощениями? В моем псевдокоде каждой записи в базе соответствует одна строчка. Сколько же данных надо вбивать в базу для теста? Может, Ваша хранимка делает слишком много? Если не секрет, что это за тест такой, что надо 50 записей готовить? Или это 50 таблиц, в каждую по записи?

Хранимая процедура объединяет две запчасти в одну группу замен (т.е. сохраняет информацию что эти запчасти заменяют друг друга). Вначале надо проверить что запчасти могут быть объединены, а потом возможны разные случаи, например что если запчасти в разных группах замен, или что если это новые запчасти, тогда надо создать новую группу замен для них сначала и т.д.
Ну и соответственно нужно подготовить разные случаи, в том числе приводящие к ошибке (т.е. когда невозможно запчасти объединить в одну группу замен). Может насчет пары страниц я переборщил, но думаю что страница кода уйдет на подготовку этих данных. Может я вообще зря парюсь?

MC>>Кстати с копией реальной БД удобно тем, что нередко в базе уже есть данные по которым можно тест написать.

ulu>Я, по природе, человек очень ленивый. И писать лишний код мне всегда влом.
По-моему это цитата из МакКоннелла

ulu>Поэтому я тоже старался пользоваться уже готовыми данными. Но это повернулось против меня, как я уже писал.

ulu>Возьмите базу с готовыми данными, сделайте скрипт, который вставляет в базу эти данные, и пользуйтесь им при создании тестовой базы. У Вас будет вполне предсказуемая тестовая база (взамен непредсказуемой реальной), и не придется данные вставлять в коде.

К этому все-таки и склоняюсь пока.

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

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

MC>>>Я вообще-то как раз от этого и хочу избавиться. Мне сейчас чтобы протестировать 1 ХП нужно тест на 2-3 страницы написать, потому что большая часть будет подготовка данных.
ulu>>См. рецепт упрощения работы ниже. Если грамотно запариться, то потом все будет просто.
MC>А у вас класс DbUtils на что завязан? Я к тому что можно ли было бы мне его заиметь и подделать под мой MySql.

DbUtils -- это я на ходу выдумал

MC>>>А зачем мне смотреть на тест? Я его один раз написал и забыл. Если он вдруг упадет через 2 года, ну что ж — залезу в базу и гляну.
ulu>>Если приложение будет активно развиваться, то вполне вероятно, что тесты будут время от времени падать.
MC>У меня приложение активно развивается, а тесты редко падают.. Может я супер крут? Или мало тестов и они слабые?..

Редко падают -- это нормально. Но ведь не раз в два года же. Я вначале воспринял фразу про 2 года буквально..

ulu>>И понадобится срочно понять, что тут происходит. А через два года, чтобы во всем этом разобраться, уйдет гораздо больше времени, чем написать приличный и понятный тест.
MC>Это да, недавно как раз большой тест упал, полчаса убил чтобы вникнуть как работает эта мешанина, которую я написал год назад . Но опять же, такое бывает очень редко...

MC>>>Выглядит неплохо, но, как я уже много раз писал, иногда код по подготовке тестовых данных занимает 2 страницы кода и даже из-за этого не хочется тест писать. Вот это и хочется как-то упростить, сделать удобнее. Либо вообще подойти с какой-то другой стороны.

ulu>>Что, даже со всеми упрощениями? В моем псевдокоде каждой записи в базе соответствует одна строчка. Сколько же данных надо вбивать в базу для теста? Может, Ваша хранимка делает слишком много? Если не секрет, что это за тест такой, что надо 50 записей готовить? Или это 50 таблиц, в каждую по записи?

MC>Хранимая процедура объединяет две запчасти в одну группу замен (т.е. сохраняет информацию что эти запчасти заменяют друг друга). Вначале надо проверить что запчасти могут быть объединены, а потом возможны разные случаи, например что если запчасти в разных группах замен, или что если это новые запчасти, тогда надо создать новую группу замен для них сначала и т.д.
MC>Ну и соответственно нужно подготовить разные случаи, в том числе приводящие к ошибке (т.е. когда невозможно запчасти объединить в одну группу замен). Может насчет пары страниц я переборщил, но думаю что страница кода уйдет на подготовку этих данных. Может я вообще зря парюсь?

Тогда это будет много тестов, по одному на каждый случай, и у каждого будут свои начальные данные (разве что группы замен можно создать один раз для всех тестов), но для каждого конкретного теста данных будет сравнительно немного -- пара запчастей.

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

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

ulu>Вообще, я не знаю, насколько Вы можете тут решать, но это все бизнес-логика, и непонятно, зачем ее помещать в базу.
В основном такие решения исходят из соображений производительности. Например добавление замен может вызываться в некотором цикле много раз — ХП в данном случае отработает заметно быстрее (у меня двухзвенка, если что, это тоже влияет на принятие решений).

ulu>Если бы это был код приложения, то очень легко было бы изменить дизайн так, чтобы можно было писать маленькие тесты на маленькие кусочки функциональности.
Я знаю, но практика жестока

> OS>Я пару раз наступал на такие проблемы.
> OS>ИМХО самы прямой путь — иметь в проекте файлик вроде SetupDb.sql. База
> OS>данных создаваемая этим файлом и есть эталонная схема БД (для заданной
> OS>версии проекта). В дальнейшем для тестов использующих БД использовать
> OS>базовый класс тесткейза в котором в setUp и tearDown создается (и
> OS>удаляется) БД на основе файла SetupDb.sql. В самом тесте в setUp может
> OS>использоваться другой SQL файл с данными чтобы заполнить БД тестовыми
> OS>данными.
>
> Но я как раз написал, что в этом случае подготовка тестовых данных может
> быть геморойной, в этом и проблема для меня. Мне вот например сейчас
> чтобы протестировать работу ХП нужно тестовых данных добавить, что
> займет 1-2 страницы кода.

Если есть схема БД в виде sql файла и базовый класс для тестов который
поднимает свежую копию БД для каждого теста, то тестовые данные для
проверки работы хранимой процедуры можно положить в отдельный SQL файл
рядом с самим тестом. При проверке хранимой процедуры базовый класс
теста поднимет свежую базу, сам класс теста зальет данные для проверки
хранимой процедуры и затем будет выполнен тест. Любые привнесенные
дефекты будут надежно отлавливаться таким тестом.
Если процедура изменится настолько (сама процедура должна быть в SQL
файле который является схемой БД), что перестанет правильно выдавать
результаты — получим ошибку на ассерте в тесте.
Если схема БД изменится настолько, что процедура не пройдет валидацию,
получим исключение в setUp базового тестового класса.
Если схема БД изменится настолько, что данные для тестов не подойдут для
загрузки в эту базу — получим исключение в методе setUp теста.

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

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

ulu>>Вообще, я не знаю, насколько Вы можете тут решать, но это все бизнес-логика, и непонятно, зачем ее помещать в базу.
MC>В основном такие решения исходят из соображений производительности. Например добавление замен может вызываться в некотором цикле много раз — ХП в данном случае отработает заметно быстрее (у меня двухзвенка, если что, это тоже влияет на принятие решений).

ulu>>Если бы это был код приложения, то очень легко было бы изменить дизайн так, чтобы можно было писать маленькие тесты на маленькие кусочки функциональности.
MC>Я знаю, но практика жестока

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

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

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


ulu>Вообще, я не знаю, насколько Вы можете тут решать, но это все бизнес-логика, и непонятно, зачем ее помещать в базу. Если бы это был код приложения, то очень легко было бы изменить дизайн так, чтобы можно было писать маленькие тесты на маленькие кусочки функциональности.


Почему разбивать на кусочки можно только код приложения? В ХП это тоже можно, собственно об этом я и писал в данной ветке, другое дело что на процедурном языке это сделать сложнее, чем на ОО