| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| 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 provenir soit du code de PostgreSQL soit des routines système de la plateforme hôte. Dans ce dernier cas, les messages pourraient varier entre plateformes mais devraient toujours refléter des informations similaires. Ces différences dans les messages résulteront dans un test de régression << échoué >> qui pourrait être validé après vérification.
Si vous lancez des tests sur un serveur déjà installé mais initialisé avec une locale autre que C, alors il pourrait y avoir des différences dans les ordres de tris. La suite de tests de régression est initialisée pour gérer ce problème en fournissant des fichiers de résultats alternatifs qui ensemble gèrent 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 beaucoup d'autres locales. Le pilote des tests de régression choisira automatiquement le meilleur fichier lors de la vérification et pour la calcul des différences d'échecs. (Ceci signifie que les tests de régression ne peuvent pas détecter si les résultats sont appropriés pour la locale configurée. Ils vont simplement récupérer le fichier résultat qui fonctionne le mieux.)
Si, pour une quelconque raison, les fichiers attendus ne couvrent pas certaines locales, vous pouvez ajouter un nouveau fichier. Le schéma de nommage est nom_test_chiffre.out. Le chiffre n'a en fait pas de signification. Rappelez-vous que le pilote des tests de régression considérera tous les fichiers comme étant des résultats de tests valides. Si les résultats de tests sont spécifiques à une plateforme, la technique décrite dans Section 26.3 devrait être utilisée à la place.
Quelques requêtes des tests d'horologie échoueront si vous lancez les tests un jour de changement de heure ou le lendemain de ce jour. Ces requêtes s'attendent à ce que les intervalles entre minuit hier, minuit aujourd'hui et minuit demain soient exactement 24 heures -- ce qui est faux lorsqu'un changement d'heure intervient.
Note : Comme les règles de changement d'heure des USA sont utilisées, ce problème arrive toujours le premier dimanche d'avril, le dernier dimanche d'octobre et les lundis suivants quelque soit le changement d'heure effectif où vous vivez. Notez aussi que le problème apparaît ou disparaît à minuit, UTC-7 ou UTC-8, pas à un minuit chez vous. Donc, l'échec pourrait arriver plus tard le dimanche ou persister jusqu'au mardi suivant l'endroit où vous vivez.
La plupart des résultats date/heure sont dépendants de l'environnement de zone horaire. Les fichiers de référence sont générés pour la zone horaire PST8PDT (Berkeley, Californie), et il y aura des échecs apparents si les tests ne sont pas lancés avec ce paramétrage de fuseau horaire. Le pilote des tests de régression initialise la variable d'environnement PGTZ à PST8PDT ce qui nous assure normalement de bons résultats.
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.
Le script de tests random a pour but de produire des résultats aléatoires. Dans de rares cas, ceci fait échouer random aux tests de régression. 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
| Précédent | Sommaire | Suivant |
| Tests de régression | Niveau supérieur | Fichiers de comparaison spécifiques à la plateforme |