PostgreSQLLa base de données la plus sophistiquée au monde.

29. Tests de régression

Les tests de régression composent un ensemble exhaustif de tests pour l'implémentation SQL dans PostgreSQL™. Ils testent les opérations SQL standards ainsi que les fonctionnalités étendues de PostgreSQL™.

29.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, ils peuvent être lancés en mode « parallèle » ou en mode « séquentiel ». Le mode séquentiel lance les scripts de test en série, tandis que le mode parallèle lance plusieurs processus serveurs pour parallèliser l'exécution des groupes de tests. Les tests parallèles permettent de s'assurer du bon fonctionnement des communications interprocessus et du verrouillage. Pour des raisons historiques, les tests séquentiels sont habituellement lancés sur une installation existante et la méthode parallèle préférentiellement sur une installation temporaire, mais il n'y a aucune raison technique à cela.

Pour lancer les tests de régression 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 29.2, « Évaluation des tests » avant de supposer qu'un « échec » représente un problème sérieux.

[Avertissement]

Avertissement

Sur les systèmes ne disposant pas de sockets de domaine Unix, la méthode de tests démarre un serveur temporaire configuré pour accepter toute connexion provenant de la machine locale. Tout utilisateur local peut obtenir les droits superutilisateur de la base de données en se connectant à ce serveur et pourrait en principe exploiter tous les droits de l'utilisateur du système d'exploitation exécutant les tests. De ce fait, il n'est pas recommandé d'utiliser gmake check sur un système partagé avec d'autres utilisateurs. À la place, lancez les tests après avoir terminé l'installation, comme indiqué dans la section suivante.

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