| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Chapitre 26. Tests de régression | Avance rapide | Suivant |
Il arrive parfois qu'une instance de PostgreSQL, correctement installée et entièrement fonctionnelle, puisse << échouer >> à certains tests de régression, du fait de spécificités de la plateforme. Ces spécificités peuvent, par exemple, être la représentation des nombres à virgules flottantes ou le support des fuseaux horaires. Les tests sont, à ce jour, évalués en utilisant une simple comparaison diff avec les sorties engendrées sur un système de référence. Les résultats sont donc sensibles à de petites différences système. Lorsqu'un test est annoncé << échoué >>, il faudra examiner les différences entre les résultats attendus et obtenus ; il est probable que les différences ne soient pas significatives. Néanmoins, tout est fait pour maintenir des fichiers de références précises et actualisées pour toutes les plateformes supportées avec un soucis constant de réussite des tests.
Les sorties actuelles des tests de régression sont stockées dans les fichiers du répertoire src/test/regress/results. Chaque fichier de sortie est comparé (diff) aux sorties de référence stockées dans le répertoire src/test/regress/expected. Les différences sont stockées dans le fichier src/test/regress/regression.diffs. La diff peut également être lancée par l'utilisateur.
Certains des tests de régression impliquent des valeurs en entrée intentionnellement invalides. Les messages d'erreur peuvent alors provenir, soit du code de PostgreSQL, soit des routines système de la plateforme hôte. Dans ce cas, les messages peuvent varier en fonction des plateformes mais ils doivent toujours refléter des informations similaires. Des différences dans les messages produiront l'<< échec >> du test de régression, qui pourra être validé après vérification.
Si des tests sont initiés sur un serveur, déjà installé, initialisé avec une régionalisation des sous-tri différente de C, il peut y avoir des différences dues aux ordres de tris. La suite de tests de régression gère ce problème à l'aide de fichiers de résultats alternatifs tenant compte d'un grand nombre de locales. Par exemple, pour le test char, le fichier char.out attendu gère les locales C et POSIX, et le fichier char_1.out gère un grand nombre de locales différentes. Le pilote des tests de régression choisira automatiquement le meilleur fichier. (Les tests de régression ne détectent pas la pertinence des résultats pour la locale configurée. Ils récupèrent le fichier résultat qui fonctionne le mieux.)
Si, pour une raison quelconque, les fichiers existants ne couvrent pas certaines locales, il est possible d'ajouter un nouveau fichier. Le schéma de nommage est nom_test_chiffre.out. Le chiffre n'a aucune signification. Le pilote des tests de régression considère tous ces fichiers comme des résultats également valides de tests. Si les résultats de tests sont spécifiques à une plateforme, il faudra utiliser la technique décrite dans Section 26.3.
Quelques requêtes des tests d'horologie échoueront si ces tests sont réalisés un jour de changement d'heure ou le lendemain de ce jour. Ces requêtes s'attendent à ce que les intervalles entre minuit le jour précédent, minuit ce jour et minuit le lendemain soient exactement de 24 heures -- ce qui n'est plus le cas lors d'un changement d'heure.
Note : Comme ce sont les règles de changement d'heure en vigueur aux USA qui sont utilisées, ce problème survient toujours le premier dimanche d'avril, le dernier dimanche d'octobre et les lundis suivants quelque soit le jour où intervient le changement d'heure dans le pays où les tests sont lancés. Le problème apparaît et disparaît à minuit heure du Pacifique, UTC-7 ou UTC-8, pas à minuit heure locale. Il se peut que l'échec survienne plus tard le dimanche ou persiste jusqu'au mardi en fonction du lieu de test.
La plupart des résultats date/heure dépendent du fuseau horaire. Les fichiers de référence sont engendrés pour le fuseau horaire PST8PDT (Berkeley, Californie). Des échecs peuvent se produire si les tests ne sont pas lancés avec ce paramétrage du fuseau horaire. Le pilote des tests de régression initialise la variable d'environnement PGTZ à PST8PDT, ce qui assure normalement des résultats cohérents. Néanmoins, le système d'exploitation doit fournir un support du fuseau horaire PST8PDT, sinon les tests dépendant du fuseau horaire échoueront. Pour vérifier que la machine dispose de ce support, on saisira :
env TZ=PST8PDT date
La commande ci-dessus devrait renvoyer l'heure système actuelle dans le fuseau horaire PST8PDT. Si le fuseau horaire PST8PDT n'est pas disponible, il se peut que le système retourne l'heure en UTC. Si le fuseau horaire PST8PDT est manquant, les règles de fuseau horaire peuvent être spécifiées explicitement :
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
Certains systèmes n'acceptent toutefois pas la syntaxe recommandée pour initialiser explicitement les règles du fuseau horaire local. Il sera peut-être nécessaire d'initialiser différement PGTZ sur de telles machines.
Certains systèmes, enfin, utilisent d'anciennes bibliothèques de fuseaux horaires et échouent lors de l'application des changements d'heure sur les dates antérieures à 1970. Les heures PDT pré-1970 sont alors affichées en PST. Cela produira des différences localisées dans les résultats des tests.
Quelques tests impliquent des calculs sur des nombres flottants à 64 bits (double precision) à partir de colonnes de tables. Des différences dans les résultats appliquant des fonctions mathématiques à des colonnes double precision ont été observées. Les tests de float8 et geometry sont particulièrement sensibles aux différences entre plateformes, voire aux différentes options d'optimisation des compilateurs. L'œil humain est nécessaire pour déterminer la véritable signification de ces différences, habituellement situées après la dixième décimale.
Certains systèmes affichent moins zéro comme -0 alors que d'autres affichent seulement 0.
Certains systèmes signalent les erreurs des fonctions pow() et
exp() différemment du mécanisme attendu par le
code de PostgreSQL.
Des différences peuvent apparaître entre l'ordre d'affichage des lignes et celui du fichier de référence. Dans la plupart des cas, il ne s'agit pas vraiment d'un bogue. La plupart des scripts de tests de régression ne sont pas assez stricts pour utiliser un ORDER BY sur chaque SELECT. De ce fait, l'ordre des lignes n'est pas forcément défini suivant la spécification SQL exacte. En pratique, les mêmes requêtes étant exécutées sur les mêmes données avec le même logiciel, le même tri des résultats est généralement obtenu sur toutes les plateformes et le manque d'ORDER BY ne pose pas de problème. Il se peut toutefois que quelques requêtes affichent des différences de tri entre plateformes. (Ces différences peuvent aussi être la conséquence d'une locale différente de C.)
Ainsi, il n'y a pas lieu de s'inquiéter d'une différence de tri, sauf si la requête possède un ORDER BY que le résultat ne respecte pas. Il est alors intéressant de faire remonter cette information, afin qu'un ORDER BY soit ajouté à cette requête pour éliminer les faux << échecs >> dans les versions suivantes.
Si toutes les requêtes ne sont pas ordonnées, c'est simplement parce que cela rendrait les tests de régression moins utiles. En effet, ils tendraient à exercer des plans de requêtes produisant des résultats ordonnés excluant ainsi les autres types de plans.
Il existe au moins un cas dans le script de tests de random qui a pour but de produire des résultats aléatoires. Ceci fait échouer random aux tests de régression une fois de temps en temps (peut-être une fois toutes les cinq à dix tentatives). Saisir
diff results/random.out expected/random.out
ne devrait produire au plus que quelques lignes différentes. Cela est normal et ne devient préoccupant que si les tests random échouent en permanence lors de tests répétés. (De la même façon, il faudra se préoccuper d'un test random qui n'échouerait jamais.)
| Précédent | Sommaire | Suivant |
| Tests de régression | Niveau supérieur | Fichiers de comparaison spécifiques à la plateforme |