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). Les tests exécutés en parallèle sont préfixés avec « + », et les tests exécutés séquentiellement sont préfixés avec « - ». Au final, la sortie devrait ressembler à quelque chose comme

======================
 All 213 tests passed.
======================

ou une note indiquant l'échec des tests. Voir la Section 33.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 17), initialisez un répertoire de données et lancez le serveur comme expliqué dans le Chapitre 19, 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.

Certaines des suites de tests supplémentaires utilisent l'infrastructure TAP expliquée dans Section 33.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 parce qu'ils nécessitent un logiciel spécifique, soit parce qu'elles consomment beaucoup de ressources. 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 load_balance'
    

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.

Un paramétrage personnalisé du serveur peut être configuré dans la variable d'environnement PGOPTIONS pour les tests qui suivront (pour les paramètres qui le permettent) :

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

Lors de l'exécution sur une installation temporaire, un paramétrage personnalisé peut aussi être configuré en fournissant un fichier postgresql.conf déjà configuré :

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

Ceci peut être utile pour activer des traces supplémentaires, pour ajuster les limites en ressource ou pour activer des vérifications supplémentaires à l'exécution, telles que debug_discard_caches.

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