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

make check

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

=======================
 All 115 tests passed.
=======================

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

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

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

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

make MAX_CONNECTIONS=10 check

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

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

make installcheck

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

make installcheck-parallel

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

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

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

make check-world
make installcheck-world

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

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

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

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

По умолчанию, тесты, работающие на временной инсталляции, используют локаль, определённую в текущей среде и кодировку базы данных, заданную при выполнении 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; в противном случае кодировка определяется автоматически из локали, и установка кодировки, не соответствующей локали, приведёт к ошибке.

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

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

make check EXTRA_TESTS=numeric_big

Запустить тест сортировки:

make check EXTRA_TESTS=collate.linux.utf8 LANG=en_US.utf8

Тест collate.linux.utf8 работает только на платформе Linux/glibc и выполняется только для баз данных с кодировкой UTF-8.

Исходный дистрибутив также содержит регрессионные тесты для статического поведения сервера горячего резерва. Для выполнения тестов требуется работающий ведущий сервер и работающий резервный, принимающий новые записи 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.