Чтобы запустить параллельное регрессионное тестирование после сборки, но до инсталляции, наберите:

make check

в каталоге верхнего уровня. (Или, как вариант, вы можете перейти в src/test/regress и выполнить команду там.) По завершении процесса вы должны увидеть нечто вроде:

=======================
 All 193 tests passed.
=======================

или список тестов, не пройденных успешно. Прочитайте Раздел 33.2, прежде чем делать вывод о серьёзности выявленных «проблем».

Поскольку данный метод тестирования выполняется на временном сервере, он не будет работать, если вы выполняете сборку под пользователем root, сервер просто не запустится из под root. Рекомендуется не делать сборку под пользователем root, если только вы не собираетесь проводить тестирование после завершения инсталляции.

Если вы сконфигурировали PostgreSQL для инсталляции в месте, где уже установлена предыдущая версия PostgreSQL, и вы выполняете make check до инсталляции новой версии, вы можете столкнуться с тем, что тестирование завершится со сбоем, поскольку новая программа будет пытаться использовать уже установленные общие библиотеки. (Типичные симптомы - жалобы на неопределённые символы.) Если вы хотите провести тестирование до перезаписи старой инсталляции, вам необходимо проводить построение с configure --disable-rpath. Однако этот вариант не рекомендуется для окончательной инсталляции.

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

make MAX_CONNECTIONS=10 check

выполняет не больше десяти тестов параллельно.

Чтобы запустить тестирование после инсталляции (см. Главу 17), инициализируйте каталог данных и запустите сервер, как показано в Главе 19, потом введите:

make installcheck

или для параллельного тестирования:

make installcheck-parallel

Тестовые сценарии будут соединяться с сервером на локальном компьютере с номером порта по умолчанию, если иное не задано переменными среды PGHOST и PGPORT. Тестирование будет проведено в базе данных regression; любая существующая база с таким именем будет удалена.

Также тесты будут создавать для временного пользования объекты, общие для кластера, такие как роли, табличные пространства и подписки. Имена этих объектов будут начинаться с regress_. Остерегайтесь использования режима installcheck там, где такие имена могут иметь существующие глобальные объекты.

Команды make check и make installcheck запускают только «основные» регрессионные тесты, которые проверяют встроенную функциональность сервера PostgreSQL. Исходный дистрибутив содержит множество других пакетов тестов, большая часть которых имеет дело с дополнительной функциональностью, такой, как, например, дополнительные процедурные языки.

Чтобы запустить пакет тестов (включая основные) применительно к модулям, выбранным для построения, наберите одну из этих команд в каталоге верхнего уровня дерева сборки:

make check-world
make installcheck-world

Эти команды запускают тестирование, используя временный или уже установленный сервер, в соответствии с данным выше описанием для команд make check и make installcheck. Остальные детали соответствуют ранее изложенным объяснениям для каждого метода. Необходимо иметь в виду, что команда make check-world создаёт экземпляр кластера (временный каталог данных) для каждого тестировочного модуля, а это требует гораздо больше времени и дискового пространства, нежели команда make installcheck-world.

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

make check-world -j8 >/dev/null

Значение для -j обычно ограничивается количеством ядер или может быть немного больше. Подавление вывода в stdout избавляет от большого объёма сообщений, не представляющих интереса, когда нужно просто убедиться в успешности проверки. (В случае ошибки выводимые в stderr сообщения обычно дают достаточно информации для диагностики проблемы.)

В качестве альтернативного пути можно запустить индивидуальный пакет тестов, набрав make check или make installcheck в подходящем подкаталоге дерева сборки. Имейте в виду, что make installcheck предполагает, что вы уже установили соответствующие модули, а не только основной сервер.

Дополнительные тесты, которые можно активизировать таким способом:

При использовании режима installcheck эти тесты будут создавать и удалять базы данных с именами, включающими слово regression, например pl_regression или contrib_regression. Остерегайтесь использования этого режима там, где имеются базы с такими именами, не предназначенные для тестирования.

Некоторые из этих дополнительных пакет тестов используют инфраструктуру TAP, описанную в Разделе 33.4. TAP-тесты выполняются, только когда PostgreSQL конфигурируется с ключом --enable-tap-tests. Этот ключ рекомендуется для разработки, но если подходящей инсталляции Perl нет, его можно опустить.

Некоторые пакеты не запускаются по умолчанию — одни потому, что выполнять их в многопользовательской системе небезопасно, а другие потому, что им требуется специальное программное обеспечение. Эти пакеты тестов можно включить дополнительно, присвоив переменной PG_TEST_EXTRA (это может быть переменная окружения или скрипта make) строку с их списком через пробел, например:

make check-world PG_TEST_EXTRA='kerberos ldap ssl'

В настоящее время поддерживаются следующие значения:

Тесты функциональности, которая не поддерживается в текущей конфигурации сборки, не запускаются, даже если они указаны в PG_TEST_EXTRA.

Кроме того, в каталоге src/test/modules есть тесты, которые будут запускаться в режиме make check-world, но не в make installcheck-world. Это объясняется тем, что они имеют побочные эффекты или устанавливают расширения, неподходящие для производственной среды. По желанию вы можете выполнить make install или make installcheck в одном из его подкаталогов, но делать это с сервером, не предназначенным для тестирования, не рекомендуется.

По умолчанию, тесты, работающие на временной инсталляции, используют локаль, определённую в текущей среде и кодировку базы данных, заданную при выполнении initdb. Для тестирования различных локалей может оказаться полезным установить подходящие переменные среды, например:

make check LANG=C
make check LC_COLLATE=en_US.utf8 LC_CTYPE=ru_RU.utf8

Поддержка переменной LC_ALL в этом случае не реализована; все остальные переменные среды, относящиеся к локали, работают.

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

Вы можете задать кодировку базы данных в переменной ENCODING, например:

make check LANG=C ENCODING=EUC_JP

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

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

При запуске пакета регрессионных тестов можно использовать пользовательские параметры сервера, задаваемые переменной окружения PGOPTIONS (если это возможно):

make check PGOPTIONS="-c force_parallel_mode=regress -c work_mem=50MB"

Когда тесты проводятся с временной инсталляцией, пользовательские параметры также можно задать в предварительно написанном postgresql.conf:

echo 'log_checkpoints = on' > test_postgresql.conf
echo 'work_mem = 50MB' >> test_postgresql.conf
make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"

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

Пакет основных регрессионных тестов содержит несколько тестовых файлов, которые не запускаются по умолчанию, поскольку они могут зависеть от платформы или выполняться слишком долго. Вы можете запустить те или иные дополнительные тесты, задав переменную EXTRA_TESTS. Например, запустить тест numeric_big:

make check EXTRA_TESTS=numeric_big

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

Для запуска тестов сервера горячего резерва необходимо создать базу данных regression на ведущем сервере:

psql -h primary -c "CREATE DATABASE regression"

Затем, на ведущем сервере в базе данных regression запустите предварительный скрипт src/test/regress/sql/hs_primary_setup.sql Например:

psql -h primary -f src/test/regress/sql/hs_primary_setup.sql regression

Убедитесь, что эти изменения распространились на резервный сервер.

Теперь, для выполнения теста, настройте, чтобы подключение по умолчанию выполнялось к резервному серверу (например, задав переменные среды PGHOST и PGPORT). И, наконец, запустите make standbycheck в каталоге регрессионных тестов:

cd src/test/regress
make standbycheck

Чтобы протестировать работу резервного сервера в некоторых экстремальных условиях, эти условия можно получить на главном, воспользовавшись скриптом src/test/regress/sql/hs_primary_extremes.sql.