TDDИмеет ли смысл в Firebird проводить юнит тестирование ХП? Какие есть инструменты?1. Да, есть смысл. Иногда такое вылезает, что сидишь думаешь сам с собою: "а как же это никто за 15 лет до сих пор не ..." :-)
2. в ФБ есть framework, разработанный П. Цизарем (Чехия) и предназначенный для прогонов тестов силами Питона. Каждый тест - это небольшой текстовый файлик, с несколькими необходимыми сексиями и кодом для прогона.
Фреймворк этот умеет не только создавать базы "на лету", но и ресторить из .fbk или просто открывать имеющиеся. Он умеет также издеваться над базами как силами ISQL (который запустит отдельным процессом "внутри себя"), так и своими собственными python-возможностями.
Вы задаете expected_stdout (при необх-сти - и expected_stderr), а также можете задать фильтацию и/или "автозамены", чтобы не анализировать только нужные строки - и получите или ОК или отлуп.
3. Есть батник для удобства прогонов всех тестов сразу и записи их результатов в отдельную базу, чтобы далее видеть историю, с возможным поиском регрессий и проч.

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

miwaonlineон "только для внутреннего использования"? Платный? Или Павел (который Цезарь :) ) просто не хочет/не думал его выкладывать?На входной двери fbtest'a сказано, что можно юзать бесплатно для чего угодно, но только текст лицензии должен быть воткнут во все копии блаблабла... miwaonlineготовый фреймворк посмотреть было бы интерессно и полезно.Раз уж авторы этого фреймворка говорят, что не против - бери его, что тут стесняться :-)

deboseК сожалению в документации отсутствует раздел про написание тестов "Writing new tests".Да, увы - но это так :(

deboseНасколько реально там сделать что-то подобное из коробки:
* перед каждым тестом запускать большой скрипт из файла (чистить бд)
* в before test запустить скрипт вставляющий данные в несколько таблиц
* в самом тесте запустить 1 sql, который сгенерит несколько десятков записей в таблице
* проверить что данные в этой таблице соответствуют эталону

?Всё это делается с полпинка. Скачайте из репозитория тесты и сходите внутрь папки %fbt-repo%\tests\bugs\, там будет тучка файлов с расширением ".fbt". В каждом из них вы увидите секцию 'test_script', а во многих - еще и секцию 'init_script'
Кроме того, в части файлов (бОльшей) будет указано делать прогон силами ISQL'я (который запустит "под собой" питон), а в другой - силами самого питона через fdb-драйвер. Это прописано в 'test_type' (т.е. там будет либо 'ISQL' либо 'Python').

База создаётся пустая (если только нет указния юзать имеющуюся, или ресторить из существующего .fbk).

Начальный скрипт (создание объектов базы) надо указывать в секции 'init_script', но если тест прогоняется силами ISQL'я (т.е. 'test_type': 'ISQL'), то можно голову не морочить и всё затолкать в основную секцию - 'test_script'.

В секции 'test_script' вы указываете, что надо делать. Если тест делается силами ISQL, то вся эта часть должна представлять из себя просто .sql-скрипт. Допускаются также "вспомогательные" команды типа set term, in ... / out ..., set list on|off, set count on etc.

В секции 'expected_stdout' вы прописываете "эталон" в потоке STDOUT, т.е. что вы ждёте там ждёте. В секции 'expected_stderr' - то, что ждёте в потоке STDERR.

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

Наконец, есть замечательная штука - "механизм подстановок" ('substitutions'). Он позволяет:
1) полностью игнорировать задушить нежелательные сообщения (или их часть), если известен их текст;
2) оставить только желательные сообщения (если известен их текст), а всё остальное - выкинуть.
Сравнение вывода с extected_* будет идти уже после применения substitutions.

Вот пример (файл %fbt-repo%\tests\bugs\core_4940.fbt ):


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

Далее, секция test_script содержит то, что надо прогнать - в данном примере это тривиальные команды 'show function ...'. Но на самом деле это м.б. SQL-скрипт любой сложности.

Затем, смотрим НЕ на extected_* секции, а сразу в подвал. И видим там subst-секцию. И в ней - питоновский regexp, запрещающий вывод всех строк, КРОМЕ тех, что содержат либо "Deterministic" либо "deterministic" (наверное, можно там и как-то через case insens выкрутиться, шаблонами его; но мне в лом было :)).

Теперь возвращаемся в expected_stdout - там записано то, что мы ждём. А в expected_stderr записано пусто - т.е. мы НЕ ждём тут ошибки на этапе выполнения.

А теперь - самое важное (я об это башку сломал, пока додумкивал; спасибо ДЕ - он в своё время наставил на путь истинный).
Чтобы выполнить прогон этого теста:

1) уйдите из каталога %fbt-repo%\tests\bugs\ на два уровня выше, т.е. в каталог %fbt-repo%; все тесты всегда должны выполняться, стоя в этом каталоге!

2) проверьте содержимое PATH. В ней должен быть указан путь к тому клиенту ФБ, который будет юзаться сейчас. Скорее всего, это будет клиент от того же инстанса ФБ, что вы собираетесь проверять. Но будьте здесь особенно внимательны: как только вздумаете проверять другую версию ФБ, немедленно затолкайте в голову PATH-списка путь к _новому_ fbclient'у:

3) находясь в каталоге %fbt-repo%, введите:
* для localhost'a:
* для remote-хоста:
Примечания:
3.1) указывать "C:\%Python_home%\Scripts\", скорее всего, не понадобится, т.к. питон прописывает себя и путь к scripts-подкаталогу в PATH при установке;
3.2) FB_binaries_path - каталог, где лежат бинарники FB (т.е. это fbhome\bin для версий <= 2.5 или же fbhome для 3.0)
3.3) если тест находится относительно вашего текущего каталога (%fbt_repo%) на _два_ уровня ниже, т.е. в tests\bugs\, то имя 'tests' вы *не* указываете, имя ' bugs ' отображается в виде части строки слева от точки , а имя файла - в виде части строки справа от точки . Таким обр., полное имя файла с тестом указывать нельзя. За каким псом так было сделано - хз :-)
3.4) фреймворк создаст базу там, где работает ФБ - это определяется значением после ключика '-o'. Если это локальный хост, то база создастся в каталоге %fbt-repo%\tmp. Но если это удалённый хост, или же если вам надо создавать базу в другом каталоге, то укажите '-d ....'. И обратите особое внимание: в имени каталога для времянок ("/tmp/firebird / ") завершающий слеш - обязателен.

Dimitry SibiryakovСколько места на диске требуется для этих тестов? У меня всего лишь паршивый ноутбук и чтобы не промозолить ему винт, может, можно каталог БД и временные файлы отнести на RAM-диск?..Сами файлики, конечно, просят немного:
Но вот насколько там всё раскочегаривается в рантайме - не ведаю. Я бы 1-2 гига точно оставил свободными, т.к. есть несколько тестов на "длинные сортировки", "длинные индексы" и проч.

Dimitry Sibiryakovможно каталог БД и временные файлы отнести на RAM-диск?..Лучше спроси у П.Ц., но я сильно подозреваю, что нельзя. Всё там достаточно жёстко прошито у него.

Dimitry SibiryakovВ трассировке вижу, что питон сначала пробует подключиться к БД и обламывается, потом создаёт её, потом дропает. Чего я ещё не учёл?Всё так и д.б, fbtest сам создает базу, и сам же её убивает.
Dimitry SibiryakovPS: Как этот results.trf можно привести к читабельному виду?fbt_view -d results.trf

Для запуска этого теста (и остальных тоже) делаем следующее:

1) переходим в каталог, который я называю fbt-repo - в нём должны быть видны следующие подкаталоги:

2) убеждаемся, что в переменной PATH сейчас есть путь к ФБ-инстансу, который проверяем:

3) убеждаемся, что в каталоге, где хотим, чтобы fbt_run создал базу-времянку для проверки (напр., "C:\TEMP\TRALYALYA\"), нету файла с именем bugs.core_4940.fdb .
ЭТО ВАЖНО! Если он там есть (напр., от предыдущего аварийно заваленного прогона или его срубания), то будет сбой НЕ с ошибкой собственно теста, а вот с этой хренью:

4) запускаем прогон теста, при этом указываем в "-b" путь к бинарникам ФБ, в "-o" - имя хоста и порт прослушки, а заодно даем команду fbt_view на вывод инфы с детализацией расхождений. Клиентскую библу fbtest будет НЕЯВНО искать в PATH. Автор fbtest'a (P.Cisar) добавил возможность явного указания каталога с fbclient'ом относительно недавно (в апреле с.г), это делается указанием ключика -c и полного пути и имени клиентской либы ("fbt_run ... -c c:\mix\firebird\fb30sc\fbclient.dll").
Однако, в очень многих тестах есть вызовы ФБ-бинарников типа такого: runProgram('isql', [dsn, ...]) - и ясен пень, что тут стопудово будет всё искаться через PATH. Так что ключик '-c <client_library>' полезен далеко не всегда.



::: NB :::
Если файл код теста содержится относительно каталога %fbt-repo% в файле: tests\bugs\core_4940.fbt, то указывать его надо:
1) БЕЗ префикса 'tests' (как и все остальные файлы, которые в других подкаталогах ниже этого 'tests': functional\basic, functional\database etc - т.е. НИКОГДА не указываем в командной строке 'tests');
2) разделители каталогов, которые идут дальше, заменяем на символ "." (точку);
3) расширение .fbt - не указываем.
Например, для прогона теста tests\functional\basic\db\db_01.fbt указываем вот это: functional.basic.db.db_01

По окончании теста на консоль вылезет либо сообщение об успешном итоге: либо что-то на тему expected stdout/stderr не отвечает ожидавшемуся, а в особо тяжких случаях еще и такое вот: PS. И еще.
1) если .fbt-файл содержит non-ascii символ, и это _не_ utf8 символ, то на консоль будет выведена портянка питоновского стека с вот этим: "fbtest: UnicodeDecodeError: 'utf8' codec can't decode byte 0xa1 in position NNNN: invalid start byte". Например, слово "сorrect" с первой буковкой "Эс", а не "Це", обязательно вызовет этот отлуп. Даже если оно внутри комментария какого-нибудь :-) Так что код лучше вводить в notepad++ с умалчиваемой кодировкой = utf8.
2) fbt_run при указании ему прогнать один конкретный файл... грузит к себе куда-то там ВСЕ имеющиеся файлы текущего каталога, блин! Это может показаться ахтунгом, но оказывается, так и было задумано. На мой вопрос "на хрена, блджат ?!" - последовал витиеватый ответ про перформанс и прочая и прочая. Так что - бди за кодировками!

Dimitry Sibiryakov,

никогда не думал, что ты будешь ставить ФБ в "це:\програм филез\мои документы\данные приложений\" :-)

Dimitry Sibiryakovединственная папка, куда винда не протягивает свои загребущие лапки и файлы,
соответственно, более-менее в безопасности.а что винда может/будет делать в ФБ-шными файлами, если они окажутся в обычном каталоге, типа C:\dbms\fb40\ ?