J'ai rencontré un problème étrange aujourd'hui. J'ai une chaîne textuelle comme celle-ci:
var s = " 0 1\r\n 0 0"
c'est-à-dire qu'il y a une nouvelle ligne après celle-ci. Mon environnement.NewLine est défini sur \ r \ n
Cela fait partie d'un test unitaire et les tests fonctionnent correctement depuis plusieurs mois. Maintenant, lorsque j'exécute mes tests, la déclaration de chaîne ci-dessus entraîne:
" 0 1\r\n 0 0"
au lieu de
" 0 1\n 0 0"
Cela signifie que les tests échouent.
J'ai vidé chaque personnage pour prouver que c'est vrai. J'ai également essayé de ne pas utiliser de chaîne verbatim à la place comme ceci:
var s = @" 0 1 0 0"
et les tests passent ensuite.
Quelqu'un a-t-il une idée de ce qui pourrait se passer ici?
3 Réponses :
Si vous souhaitez utiliser la chaîne dans un test unitaire, il est préférable de vous assurer que le contenu est toujours le même. Je suggère de le déclarer comme ceci:
var s = $" 0 1{Enviroment.NewLine}0 0";
Environment.NewLine ne peut-il pas changer? J'apprécie son improbable. Mieux vaut utiliser \ r \ n explicitement
Enviroment.NewLine peut être différent selon le système d'exploitation que le logiciel exécute. Cela dépend de la façon dont le test unitaire est mis en œuvre s'il se cassera ou non. Si vous utilisez Enviroment.NewLine aux deux endroits, cela n'interrompra pas le test unitaire.
c'est un bon point, je devrais écrire les données en utilisant environment.newline.
La réponse est la suivante: Git a (très probablement) remplacé les fins de ligne dans le fichier par LF uniquement. Dépendre des fins de ligne de fichier dans les tests unitaires n'est pas une bonne idée, j'ai donc changé le code pour spécifier les nouvelles lignes explicitement dans tous les cas, donc:
var s = " 0 1\r\n 0 0"
Vous pouvez utiliser l'interpolation de chaîne avec verbatim pour ajouter des caractères de contrôle.
var s = @$" 0 1{'\r'}
0 0"
Peut-être que votre fichier source n'a littéralement que
\n- avez-vous essayé de supprimer la rupture et de l'insérer à nouveau, ou bien avez-vous jeté un coup d'œil au fichier avec quelque chose qui peut y afficher les octets réels?C'est ça! J'ai essayé de copier et coller le code dans notepad ++ mais évidemment, quand je l'ai fait, cela a corrigé les fins de ligne. Si j'ouvre le fichier directement, les fins de ligne pour une raison quelconque ont été changées en LF #
Selon une fin de ligne spécifique est dangereux. Un logiciel de contrôle de source (par exemple, Git) peut convertir les fins de ligne en push ou pull en fonction des paramètres de l'utilisateur.
@cremor oui je viens d'apprendre une leçon importante là-bas.
Je pense que ça a dû être git qui l'a fait. :)