О тестировании udf-ки

Мне нравится читать отчёты о том, как программисты решают поставленные задачи. Особенно, если запись достаточно подробная и включает в себя постановку задачи, рассмотрение альтернатив, принятие решений, совершение ошибок и их анализ.

После недавней перекомпиляции udf-ки для Firebird, я подумал, что неплохо бы её как-нибудь протестировать, чтобы убедиться что:

1. она работает на Firebird 2.1.x
2. будет работать и на других версиях сервера(опционально)
3. работает так же как и последняя версия, считающаяся стабильной
4. нормально переносит многопоточность
5. не вызывает утечек памяти

Тестировать нужно и под Linux и под Windows, да ещё и для 64-битных версий(в будущем), и что для этого наверняка понадобится по многу раз вызывать функции на разных серверах. Udf-ка экспортирует 70 функций.

Решил, что проще написать программку для тестирования. Набросал примерный план, запланировав закончить всё за три дня.

С программой на первый взгляд всё выглядело просто. Нужна была программа, которой можно указать параметры подключения к БД, файл содержащий запросы и ожидаемые результаты, количество потоков, и возможное число повторов. Следующим этапом было бы написание сценария для тестирования функций(udf). И завершающим этапом должен был стать запуск тестов на разных серверах, благо в офисе установлены версии от 0.9 до 2.1.1.

Вообще, с тех пор как мы купили FibPlus, все последние проекты я делаю на этих компонентах. Но не так давно столкнулся с ситуацией, когда после выполнения парочки запросов на FIB-ах в отдельном потоке(с отдельным подключением к базе), приводило к появлению загадочного[1] Access Violation-а при выходе из программы. Причём после замены всех FibPlus-компонентов на аналогичные компоненты IBX для этого потока, всё заработало без видимых ошибок[2]. Так что для работы в потоках были выбраны компоненты IBX.

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

За время отладки скрипта я узнал много нового про поведение различных версий Firebird. Отлаженный на Firebird 2.1 скрипт пришлось переписать после завала всех тестов с датами и строками на Firebird 1.5. На реализацию проекта ушло примерно три рабочих дня. Получившуюся программку можно будет использовать для создания стрессовой нагрузки на сервер баз данных. Хотя, если как следует подумать, то тестирование, не учитывающее специфику работы в разных транзакциях наверное нельзя назвать верным.

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

Почитать по теме

• Обсуждение выбора между IBX и FIBPlus для реализации многопоточного приложения(sql.ru)
• Обсуждение правильной реализации работы с Firebird из нескольких потоков(sql.ru)

[1] AV происходил при разрушении одного из контролов главной формы и возникал, когда поток-виновник уже давно был разрушен. Для меня это самый неприятный вид ошибок, потому как место и возникновения причины для AV отследить ужасно сложно(приходится пошагово проходить по всему коду выполняемому от запуска программы до её завершения и тщательно анализировать правильность каждой строки).

[2] Я использую FibPlus 6.9.5. FIB-ы были скомпилированы без директивы NO_GUI. Кое-что о проблемах с многопоточностью в FIB-ах можно почитать тут и на официальном форуме, тут.