Chapitre 26. Tests de r�gression

Table des mati�res
26.1. Lancer les tests
26.2. �valuation des tests
26.2.1. Diff�rences dans les messages d'erreurs
26.2.2. Diff�rences au niveau des locales
26.2.3. Diff�rences au niveau des dates/heures
26.2.4. Diff�rences sur les nombres � virgules flottantes
26.2.5. Diff�rences dans le tri des lignes
26.2.6. Test <<�random�>>
26.3. Fichiers de comparaison sp�cifiques � la plateforme

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.

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

ou une note indiquant l'�chec des tests. Voir la 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 en terme de s�curit�>> 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 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 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. 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 le Chapitre 14), initialisez un espace de donn�es et lancez le serveur comme expliqu� dans le 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.