Длительная загрузка тестовых данных.

Тестирование программ, работающих с СУБД, часто требует длительной загрузки тестового набора данных.

В принципе обычно всё организуется так, чтобы такая загрузка выполнялась как можно реже (в идеале не более одного раза).

Однако, тестирование грамотнее проводить на как минимум двух состояниях СУБД - пустой базе и "заполненной". Иногда "заполнений" может быть несколько.

И тут возникают проблемы:

1. При работе с тестами необходимо следить, чтобы каждый тест запускался на своём состоянии СУБД. Если запускаются друг за другом тесты, требующие разных состояний, то требуется "перенаполнять" СУБД.
2. Если тест выполнился "неудачно" и, скорее всего, испортил СУБД, то требуется опять перезаполнять СУБД "правильными" тестовыми данными.
3. При начале работы теста невозможно быстро определить, залиты ли "правильные" данные в СУБД, и не испорчены ли они.

Для решения этих проблем в izh_test был введён механизм "внутренних переменных" . В частности в такой внутренней переменной можно держать строку, указывающую на "состояние" СУБД.

Механизм использования этих переменных можно продемонстрировать следующим тестовым скриптом :

<test_script> <items> <if_property_not_equal> <name>db_state</name> <value>db_state_required_for_this_test</value> <items> .. fill db with right content .. </items> </if_property_not_equal> <set_property> <name>db_state</name> <value>db_state_changed_by_this_test</value> </set_property> 1. .. original test actions .. 2. .. actions to return DB content to original state db_state_required_for_this_test .. <set_property> <name>db_state</name> <value>db_state_required_for_this_test</value> </set_property> </items> </test_script>

В приведённом примере тест сам знает, какое состояние СУБД ему нужно и при необходимости сам заливает свои тестовые данные. Если же тест запускается после другого теста, который уже залил все необходимые данные, то соответственно и заливки не требуется.

Причём, строго говоря, выполнение команд скрипта должно продолжаться после

"1. .. original test actions .."

только в случае если оригинальный тест закончился удачно и изменил состояние СУБД именно ожидаемым способом, после которого всё можно вернуть в нужное состояние действиями

"2. .. actions to return DB content to original state db_state_required_for_this_test ..".

Тут получается определённая трудность с тем, как определить, испортил ли неудачный тест данные до такой степени, что их невозможно восстановить коротким скриптом. Пока непонятно как такую трудность решать. Возможно, только вручную указывая, когда нужно сбивать переменную - состояние СУБД, а когда нет. А в совсем запущенных случаях просто вручную чистить состояние всех внутренних переменных, заставляя систему явно перезаливать тестовые данные.

Чтобы обеспечить инициализацию базы данных перед каждым тестом, можно описать необходимые действия в виде именованного шаблона и обязать запускать этот скрипт перед каждым терминальным тестом при помощи конструкции on_start_terminal и вызова именованного шаблона

Работающий пример можно посмотреть в описании тестирования php-страницы .