Pour lancer les tests de régression en parallèle après la construction mais avant l'installation, il suffit de saisir

gmake check

dans le répertoire de premier niveau (on peut aussi se placer dans le répertoire src/test/regress et y lancer la commande). En premier lieu seront construits différents fichiers auxiliaires, tels des exemples de fonctions de déclencheurs utilisateur, puis le script de pilotage des tests sera exécuté. Au final, la sortie devrait ressembler à quelque chose comme

======================
 All 100 tests passed.
======================

ou une note indiquant l'échec des tests. Voir la Section 30.2, « Évaluation des tests » avant de supposer qu'un « échec » représente un problème sérieux.

Comme cette méthode de tests fonctionne sur un serveur temporaire, elle ne fonctionnera pas en tant qu'utilisateur root (car le serveur refusera de se lancer en tant qu'utilisateur root) Si vous avez lancé la construction en tant que root, vous n'avez pas besoin de tout recommencer. À la place, rendez le répertoire des tests de régression modifiable par un autre utilisateur, devenez cet utilisateur et relancez les tests. Par exemple

root# chmod -R a+w src/test/regress
root# su - joeuser
joeuser$ cd répertoire construction haut niveau
joeuser$ gmake check

(le seul « risque en terme de sécurité » est que les autres utilisateurs pourraient modifier les résultats des tests de régression dans votre dos. Utilisez le bon sens pour gérer les droits des utilisateurs.)

Autrement, lancez les tests après l'installation.

Si vous avez configuré PostgreSQL™ pour qu'il s'installe dans un emplacement où existe déjà une ancienne installation de PostgreSQL™ et que vous lancez gmake check avant d'installer la nouvelle version, vous pourriez trouver que les tests échouent parce que les nouveaux programmes essaient d'utiliser les bibliothèques partagées déjà installées (les symptômes typiques sont des plaintes concernant des symboles non définis). Si vous souhaitez lancer les tests avant d'écraser l'ancienne installation, vous devrez construire avec configure --disable-rpath. Néanmoins, il n'est pas recommandé d'utiliser cette option pour l'installation finale.

Les tests de régression en parallèle lancent quelques processus avec votre utilisateur. Actuellement, le nombre maximum est de vingt scripts de tests en parallèle, ce qui signifie 40 processus : il existe un processus serveur, un psql et habituellement un processus parent pour le psql de chaque script de tests. Si votre système force une limite par utilisateur sur le nombre de processus, assurez-vous que cette limite est d'au moins 50, sinon vous pourriez obtenir des échecs hasardeux dans les tests en parallèle. Si vous ne pouvez pas augmenter cette limite, vous pouvez diminuer le degré de parallélisme en initialisant le paramètre MAX_CONNECTIONS. Par exemple,

gmake MAX_CONNECTIONS=10 check

ne lance pas plus de dix tests en même temps.

Pour lancer les tests après l'installation (voir le Chapitre 15, Procédure d'installation de PostgreSQL™ du code source), initialisez un espace de données et lancez le serveur comme expliqué dans le Chapitre 17, Configuration du serveur et mise en place, puis lancez

gmake installcheck

ou pour un test parallèle

gmake installcheck-parallel

Les tests s'attendront à contacter le serveur sur l'hôte local et avec le numéro de port par défaut, sauf en cas d'indication contraire avec les variables d'environnement PGHOST et PGPORT.

La distribution source contient aussi les tests de régression pour les langages de procédures et pour certains des modules de contrib. Actuellement, ces tests peuvent seulement être utilisés avec un serveur déjà installé. Pour exécuter les tests pour tous les langages de procédure qui ont été construits et installés, placez-vous dans le sous-répertoire src/pl du répertoire de construction et lancez

gmake installcheck

Vous pouvez aussi le faire dans tous les sous-répertoires de src/pl pour lancer les tests pour un seul langage de procédure. Pour lancer les tests sur tous les modules contrib qui les ont, placez-vous dans le répertoire contrib du répertoire de construction et exécutez

gmake installcheck

Les modules contrib doivent avoir été construits et installés tout d'abord. Vous pouvez aussi le faire dans un sous-répertoire de contrib pour exécuter les tests pour un seul module.

La distribution des sources contient aussi des tests de régression du comportement statique du Hot Standby. Ces tests requièrent un serveur primaire et un serveur en attente, les deux en cours d'exécution, le dernier acceptant les modifications des journaux de transactions du primaire en utilisant soit l'envoi des fichiers soit la réplication en flux. Ces serveurs ne sont pas automatiquement créés pour vous, pas plus que la configuration n'est documentée ici. Merci de vérifier les différentes sections de la documentation qui sont déjà dévolues aux commandes requises et aux problèmes associés.

Tout d'abord, créez une base de données appelée « regression » sur le primaire.

psql -h primary -c "CREATE DATABASE regression"

Ensuite, exécutez un script préparatoire sur le primaire dans la base de données de regréssion : src/test/regress/sql/hs_primary_setup.sql, puis autorisez la propagation des modifications vers le serveur en attente. Par exemple :

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

Maintenant, confirmez que la connexion par défaut du testeur est le serveur en attente sous test, puis lancez l'action standbycheck à partir du répertoire de la suite de tests de régression.

cd src/test/regress
gmake standbycheck

Certains comportements extrêmes peuvent aussi être créés sur le primaire en utilisant le script src/test/regress/sql/hs_primary_extremes.sql pour permettre le test du comportement du serveur en attente.

Des tests automatisés supplémentaires pourraient être disponibles avec les prochaines versions.

Par défaut, les tests sur une installation temporaire utilise la locale définie dans l'environnement et l'encodage de la base de données correspondante est déterminée par initdb. Il peut être utile de tester différentes locales en configurant les variables d'environnement appropriées. Par exemple :

gmake check LANG=C
gmake check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8

Pour des raisons d'implémentation, configurer LC_ALL ne fonctionne pas dans ce cas. Toutes les autres variables d'environnement liées à la locale fonctionnent.

Lors d'un test sur une installation existante, la locale est déterminée par l'instance existante et ne peut pas être configurée séparément pour un test.

Vous pouvez aussi choisir l'encodage de la base explicitement en configurant la variable ENCODING. Par exemple :

gmake check LANG=C ENCODING=EUC_JP

Configurer l'encodage de la base de cette façon n'a un sens que si la locale est C. Dans les autres cas, l'encodage est choisi automatiquement à partir de la locale. Spécifier un encodage qui ne correspond pas à la locale donnera une erreur.

L'encodage peut être configuré pour les tests avec une installation existante ou temporaire.

La suite de tests de régression contient quelques fichiers de tests qui ne sont pas exécutés par défaut car ils pourraient dépendre de la plateforme ou prendre trop de temps pour s'exécuter. Vous pouvez les exécuter ou en exécuter d'autres en configurant la variable EXTRA_TESTS. Par exemple, pour exécuter le test numeric_big :

gmake check EXTRA_TESTS=numeric_big

Pour exécuter les tests sur le collationnement :

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

Le test collate.linux.utf8 fonctionne seulement sur les plateformes Linux/glibc et seulementquand il est exécuté sur une base de données dont l'encodage est UTF-8.