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 Cygwin, resultmap inclut

float4:out:.*-.*-cygwin.*=float4-misrounded-input.out

qui se déclenche sur toute machine où la sortie de config.guess correspond à .*-.*-cygwin.*. 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, nomtest.out, et les fichiers variants nommés nomtest_chiffre.out (où chiffre 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.