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, alors que le mode parallèle lance plusieurs processus serveur 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. Certains tests peuvent être exécutés séquentiellement même dans le mode « parallel » dans le cas où c'est nécessaire pour le test.
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 :
Les tests de régression pour les langages optionnels de procédures
stockées. Ils sont situés dans src/pl
.
Les tests de régression pour les modules contrib
,
situés dans contrib
. Tous les modules
contrib
n'ont pas forcément des suites de tests.
Les tests de régression pour les bibliothèques d'interface,
situés dans src/interfaces/libpq/test
et
src/interfaces/ecpg/test
.
Les tests pour les méthodes d'authentification supportés
nativemement, situés dans src/test/authentication
.
(Voir ci-dessous pour des tests supplémentaires relatifs à
l'authentification.)
Les tests simulant le comportement de sessions concurrentes, situés dans
src/test/isolation
.
Les tests de la restauration après crash et de la réplication
physique, situés dans src/test/recovery
.
Les tests pour la réplication logique, situés dans
src/test/subscription
.
Les tests des programmes clients, situés dans src/bin
.
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 :
kerberos
Exécute la suite de tests présent dans
src/test/kerberos
. Cela nécessite une installation
de MIT Kerberos et ouvre les sockets d'écoute TCP/IP.
ldap
Exécute la suite de tests présent dans
src/test/ldap
. Cela nécessite une installation de
OpenLDAP et ouvre les sockets d'écoute TCP/IP.
ssl
Exécute la suite de tests présent dans
src/test/ssl
. Ceci ouvre les sockets d'écoute
TCP/IP.
load_balance
Lance le test src/interfaces/libpq/t/004_load_balance_dns.pl
.
Ceci nécessite d'éduter le fichier hosts
et d'ouvrir
les sockets d'écoute TCP/IP.
wal_consistency_checking
Utilise wal_consistency_checking=all
lors de
l'exécution de certains tests sous
src/test/recovery
. Désactivé par défaut car il est
gourmand en ressources.
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