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

make 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). Au final, la sortie devrait ressembler à quelque chose comme

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

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

Comme cette méthode de tests exécute un serveur temporaire, cela ne fonctionnera pas si vous avez construit le serveur en tant que root, étant donné que le serveur ne démarre pas en tant que root. La procédure recommandée est de ne pas construire en tant que root ou de réaliser les tests après avoir terminé 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 make 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,

make 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 16), initialisez un répertoire de données et lancez le serveur comme expliqué dans le Chapitre 18, puis lancez

make installcheck

ou pour un test parallèle

make 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. Les tests seront exécutés dans une base de données nommée regression ; toute base de données existante de même nom sera supprimée.

Les tests créent aussi de façon temporaire des objets globaux, comme les rôles, les tablespaces et les abonnements. Ces objets auront des noms commençant avec regress_. Attention à l'utilisation du mode installcheck dans une installation qui a de vrais objets globaux nommés de cette manière.

Les commandes make check et make installcheck exécutent seulement les tests de régression internes qui testent des fonctionnalités internes du serveur PostgreSQL. Les sources contiennent aussi des suites supplémentaires de tests, la plupart ayant à voir avec des fonctionnalités supplémentaires comme les langages optionnels de procédures.

Pour exécuter toutes les suites de tests applicables aux modules qui ont été sélectionnés à la construction, en incluant les tests internes, tapez une des commandes suivantes dans le répertoire principal de construction :

make check-world
make installcheck-world
    

Ces commandes exécutent les tests en utilisant, respectivement, un serveur temporaire ou un serveur déjà installé, comme expliqué précédemment pour make check et make installcheck. Les autres considérations sont identiques à celles expliquées précédemment pour chaque méthode. Notez que make check-world construit une instance séparée (répertoire de données temporaire) pour chaque module testé, donc cela réclame plus de temps et d'espace disque que make installcheck-world.

Sur une machine moderne avec plusieurs CPU et sans limites au niveau du système d'exploitation, il est possible d'aller bien plus vite avec le parallélisme. La solution utilisée par de nombreux développeurs de PostgreSQL revient en fait à exécuter tous les tests ainsi :

make check-world -j8 >/dev/null
    

avec une limite au niveau de la valeur de l'option -j proche du nombre de CPU disponibles. Supprimer stdout élimine une sortie verbeuse qui n'est pas particulièrement intéressante quand on veut simplement vérifier le succès de l'opération. (En cas d'échec, les messages sur stderr sont généralement suffisant pour déterminer ce qu'il faut vérifier avec précision.)

Autrement, vous pouvez exécuter les suites individuelles de tests en tapant make check ou make installcheck dans le sous-répertoire approprié du répertoire de construction. Gardez en tête que make installcheck suppose que vous avez installé les modules adéquats, pas seulement le serveur de base.

Les tests supplémentaires pouvant être demandés de cette façon incluent :

Lors de l'utilisation du mode installcheck, ces tests créeront et supprimeront des bases de données de test dont les noms contiennent regression, par exemple pl_regression ou contrib_regression. Il faut faire bien attention à ne pas utiliser le mode installcheck avec une installation qui contient des bases de données importantes nommées de cette façon.

Certains des suites de tests supplémentaires utilisent l'infrastructure TAP expliquée dans Section 32.4. Les tests TAP sont seulement exécutés si PostgreSQL a été configuré avec l'option --enable-tap-tests. Cela est recommandé pour le développement, mais peut être omis s'il n'y a pas d'installation Perl appropriée.

Certains tests ne sont pas exécutés par défaut, soit parce qu'ils ne sont pas sécurisés pour fonctionner sur un système multi-utilisateurs, soit parce qu'ils nécessitent un logiciel spécifique. Vous pouvez décider quels seront les suites de test à exécuter lors de l'execution de make par son paramètrage ou par l'affectation d'une configuration à la variable d'environnement PG_TEST_EXTRA dans une liste séparée par des espaces, par exemple :

make check-world PG_TEST_EXTRA='kerberos ldap ssl'
    

Les valeurs suivantes sont actuellement prises en charge :

Les tests pour les fonctionnalités qui ne sont pas prises en charge par la configuration de construction actuelle ne sont pas exécutés même si elles sont mentionnées dans PG_TEST_EXTRA.

De plus, il existe des tests dans src/test/modules qui seront exécutés par make check-world mais pas par make installcheck-world. Ceci est dû au fait qu'ils installent des extensions qui ne sont pas de production ou qui ont des effets de bord considérés non désirables pour une installation en production. Vous pouvez utiliser make install et make installcheck dans un de ces sous-répertoires si vous le souhaitez mais il n'est pas recommandé de la faire sur un serveur autre qu'un serveur de tests.

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

make check LANG=C
make 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 :

make 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 de la base de données peut être configuré pour des tests sur une installation temporaire ou existante, bien que, dans ce dernier cas, il doit être compatible avec la locale d'installation.

La suite interne 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 :

make check EXTRA_TESTS=numeric_big
    

Pour exécuter les tests sur le collationnement :

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

Le test collate.linux.utf8 fonctionne seulement sur les plateformes Linux/glibc. Le test collate.icu.utf8 fonctionne seulement si le support pour ICU est présent. Les deux tests ne pourront réussir que s'ils sont effectués sur une base utilisant un encodage UTF-8.

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.

Pour exécuter les tests Hot Standby, créez une base de données appelée « regression » sur le primaire.

psql -h primary -c "CREATE DATABASE regression"
    

Ensuite, exécutez le script préparatoire src/test/regress/sql/hs_primary_setup.sql sur le primaire dans la base de données de régression. Par exemple :

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

Attendez la propagation des modifications vers le serveur en standby.

Maintenant, arrangez-vous pour que la connexion par défaut à la base de données soit sur le serveur en standby sous test (par exemple en configurant les variables d'environnement PGHOST et PGPORT). Enfin, lancez l'action standbycheck à partir du répertoire de la suite de tests de régression.

cd src/test/regress
make 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.