26.1. Lancer les tests

Les tests de régression peuvent être lancés sur un serveur déjà installé et fonctionnel ou en utilisant une installation temporaire à l'intérieur du répertoire de construction. De plus, il existe un mode << parallèle >> et un mode << séquentiel >> pour lancer les tests. La méthode séquentielle lance chaque script de test à son tour, alors que la méthode parallèle lance plusieurs processus serveurs pour exécuter des groupes de tests en parallèle. Les tests parallèles donnent une certaine indication sur le bon fonctionnement des communications interprocessus et du verrouillage. Pour des raisons historiques, les tests séquentiels sont lancé habituellement avec une installation existante alors que la méthode parallèle utilise plutôt une installation temporaire mais il n'y a aucune raison technique à cela.

Pour lancer les tests de régression après avoir lancé la construction mais avant l'installation, saisissez

gmake check

dans le répertoire de niveau haut. (Ou vous pouvez changer le répertoire par src/test/regress et y lancer la commande.) Ceci commencera par construire plusieurs fichiers auxiliaires, tels que quelques exemples de fonctions déclencheurs définies par l'utilisateur, puis lancera le script de pilotage des tests. À la fin, vous devriez voir quelque chose comme

======================
 All 96 tests passed.
======================

ou une note indiquant l'échec des tests. Voir Section 26.2 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# chmod -R a+w contrib/spi
root# su - joeuser
joeuser$ cd répertoire
construction haut niveau
joeuser$ gmake check

(Le seul << risque de sécurité >> possible ici 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 empalcement 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 symptomes 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 recommendé 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 60 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 65, 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 parameter. Par exemple,

gmake MAX_CONNECTIONS=10 check

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

Sur certains systèmes, le shell par défaut compatible Bourne (/bin/sh) a du mal à gérer autant de processus fils en parallèle. Cela pourrait causer des blocages ou des échecs dans les tests en parallèle. Dans de tels cas, spécifiez un shell compatible Bourne différent sur la liste de commande, par exemple :

gmake SHELL=/bin/ksh check

Si aucun shell ne le permet, vous pouvez contourner le problème en diminuant le nombre de connexions comme indiqué ci-dessus.

Pour lancer les tests après l'installation (voir Chapitre 14), initialisez un espace de données et lancez le serveur comme expliqué dans Chapitre 16, 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.