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 100 tests passed.
======================

ou une note indiquant l'échec des tests. Voir la Section 32.2, « Évaluation des tests » 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, Procédure d'installation de PostgreSQL™ du code source), initialisez un espace de données et lancez le serveur comme expliqué dans le Chapitre 18, Configuration du serveur et mise en place, 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ées 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 et les tablespaces. Ces objets auront des noms commençant avec regress_. Attention à l'utilisation du mode installcheck dans les installations qui ont de vrais rôles ou tablespaces 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 les constructions make check-world construisent un arbre d'installation séparé pour chaque module testé, ce qui demande à la fois plus de temps et plus d'espace disque qu'un make installcheck-world.

Autrement, vous pouvez exécuter les suites individuels 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 détruiront toute base de données nommée pl_regression, contrib_regression, isolation_regression, ecpg1_regression ou ecpg2_regression, ainsi que regression.

Les tests TAP sont seulement executé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.

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 :

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 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.