Comme certains de ces tests produisent de façon inhérente des résultats dépendants de l'environnement, nous avons fourni des moyens de spécifier des fichiers résultats alternatifs « attendus ». Chaque test de régression peut voir plusieurs fichiers de comparaison affichant les résultats possibles sur différentes plateformes. Il existe deux mécanismes indépendants pour déterminer quel fichier de comparaison est utilisé pour chaque test.
Le premier mécanisme permet de sélectionner les fichiers de comparaison
suivant des plateformes spécifiques. Le fichier de correspondance
src/test/regress/resultmap
définit le fichier de
comparaison à utiliser pour chaque plateforme. Pour éliminer les tests
« échoués » par erreur pour une plateforme particulière, vous
choisissez ou vous créez un fichier variant de résultat, puis vous ajoutez
une ligne au fichier resultmap
.
Chaque ligne du fichier de correspondance est de la forme
nomtest:sortie:modeleplateform=fichiercomparaison
Le nom de tests est juste le nom du module de tests de régression
particulier. La valeur en sortie indique le fichier à vérifier. Pour les
tests de régression standards, c'est toujours out
. La
valeur correspond à l'extension de fichier du fichier en sortie. Le modèle
de plateforme est un modèle dans le style des outils
Unix expr
(c'est-à-dire une expression rationnelle avec une
ancre implicite ^
au début). Il est testé avec le nom de
plateforme affiche par config.guess
. Le nom du fichier de
comparaison est le nom de base du fichier de comparaison substitué.
Par exemple : il manque à certains systèmes une fonction
strtof
qui fonctionne, pour laquelle notre
contournement cause des erreurs d'arrondis dans le test de régression
float4
.
Du coup, nous fournissons un fichier de comparaison
variable, float4-misrounded-input.out
, qui inclut les
résultats attendus sur ces systèmes. Pour faire taire les messages
d'« échec » erronés sur les plateformes
HP-UX 10, resultmap
inclut
+float4:out:hppa.*-hp-hpux10.*=float4-misrounded-input.out
qui se déclenche sur toute machine où la sortie de
config.guess
correspond à
hppa.*-hp-hpux10.*
. D'autres lignes dans
resultmap
sélectionnent le fichier de comparaison variable pour
les autres plateformes si c'est approprié.
Le second mécanisme de sélection des fichiers de comparaison variants est
bien plus automatique : il utilise simplement la « meilleure
correspondance » parmi les différents fichiers de comparaison fournis.
Le script pilote des tests de régression considère le fichier de comparaison
standard pour un test,
, et les
fichiers variants nommés
nomtest
.out
(où nomtest
_chiffre
.outchiffre
est un seul chiffre compris entre
0
et 9
). Si un tel fichier établit une
correspondance exacte, le test est considéré réussi ; sinon, celui qui
génère la plus petite différence est utilisé pour créer le rapport d'échec.
(Si resultmap
inclut une entrée pour le test
particulier, alors le nomtest
de base est le nom de
substitut donné dans resultmap
.)
Par exemple, pour le test char
, le fichier de comparaison
char.out
contient des résultats qui sont attendus dans
les locales C
et POSIX
, alors que le fichier
char_1.out
contient des résultats triés comme ils
apparaissent dans plusieurs autres locales.
Le mécanisme de meilleure correspondance a été conçu pour se débrouiller avec les résultats dépendant de la locale mais il peut être utilisé dans toute situation où les résultats des tests ne peuvent pas être prédits facilement à partir de la plateforme seule. Une limitation de ce mécanisme est que le pilote test ne peut dire quelle variante est en fait « correcte » dans l'environnement en cours ; il récupèrera la variante qui semble le mieux fonctionner. Du coup, il est plus sûr d'utiliser ce mécanisme seulement pour les résultats variants que vous voulez considérer comme identiquement valides dans tous les contextes.