Сравнение строк, содержащих форматирование в C #

Question

Я работаю над функцией, которая имеет некоторые настройки - например, междустрочный интервал, вывод (в виде строки) изменяется. Для тестирования таких сценариев я использую строковые литералы, как показано ниже для ожидаемого результата.

Метод, использующий построитель строк, (AppendLine) генерирует указанный вывод. Одна проблема, с которой я столкнулся, - это сравнение таких строк. В приведенном ниже примере, оба равны с точки зрения того, что они представляют. Результатом является область, которая мне небезразлична, однако при сравнении двух строк, одной литеральной, а другой - нет, равенство, естественно, не удается. Это связано с тем, что одна из строк испускает межстрочный интервал, а другая - только форматирование, которое она содержит.

Как лучше всего решить эту проблему равенства? Меня волнует форматирование, например, новые строки из результата метода, это очень важно.

Код:

string expected = @"Test\n\n\nEnd Test.";
string result = "Test\n\n\nEnd Test";

Console.WriteLine(expected);
Console.WriteLine(result);

Выход:

  Test\n\n\nEnd Test.
  Test


  End Test

Answer 1

Префикс @ указывает компилятору принимать строку в точности так, как она написана. Таким образом, он не форматирует символы \n для возврата каретки и перевода строки.

Поскольку у вас нет одинакового префикса для строки, назначенной вашей переменной result , компилятор форматирует ее. Если вы хотите продолжить использовать префикс @, просто выполните следующее:

    string expected = @"Test


End Test";

Вы должны будете вводить возврат каретки и перевод строки внутри строки как невидимые символы.

Answer 2

Вы неправильно используете термин «буквальный». «Литерал» просто означает фактическое значение, которое существует в коде. Другими словами, значения существуют в коде либо как переменные (для простоты я включаю константы в эту группу), так и литералы . Переменные являются абстрактным понятием значения, тогда как литералы являются значением .

Все это означает, что обе ваши строки являются строковыми литералами, так как они жестко запрограммированы в вашем приложении. Префикс @ просто утверждает, что компилятор должен включать в строку escape-символы (на самом деле, что угодно, кроме двойных кавычек), а не вычислять escape-последовательности при компиляции строкового литерала в сборку.

Прежде всего, независимо от того, что возвращает ваша функция (или строка, которая содержит стандартные escape-последовательности для новых строк, а не сами строки, или строка, которая фактически содержит символы новой строки), это то, что ваша тестовая переменная должна содержать . Сделайте ваши тесты как можно ближе к фактическому выводу, поскольку чем больше работы вы выполняете, чтобы преобразовать значения в сопоставимую форму, тем больше путей кода вы должны протестировать. Если вы хотите сравнить строку с форматированными escape-последовательностями, встроенными в нее, со строкой, в которой эти последовательности были оценены (по сути, сравнивая две строки в вашем примере), я бы сказал:

1. Убедитесь, что это действительно то, чего вы хотите.
2. Вам придется дублировать функциональность компилятора C #, интерпретируя эти значения и превращая вашу "строку формата" в " отформатированную строку".

Для выполнения # 2 процессор RegEx, вероятно, будет самым простым вариантом. См. на этой странице для получения списка escape-последовательностей C #.

Answer 3

Я чувствую себя несколько просвещенным, но раздражен тем, что обнаружил.

Это мой первый проект, использующий MSTest, и после неудачного теста я выбрал Просмотреть подробности теста , чтобы увидеть, как и почему мой тест не прошел. Форматирование для вывода строки в этом подробном отображении очень плохое, например, вы получаете:

Assert.AreEqual failed. Expected:<TestTest End>. Actual:<TestTest End>.

Это для форматированного текста - странная вещь, если у вас есть /r (переводы строк) вместо разрывов строк (/n), форматирование на самом деле несколько корректно.

Получается, что вы видите правильный вывод, необходимый для запуска тестов в режиме debug . Другими словами, если у вас есть провальный тест, запустите тест в отладке, и исключение будет перехвачено и отображено следующим образом:

Assert.AreEqual failed. Expected:<Test


Test End>. Actual:<Test


 Test End>.

Выше, очевидно, содержит правильное форматирование.

В итоге оказывается, что мой первоначальный метод хранения ожиданий (с форматированием) в строках был верным, но мое незнакомство с MSTest заставило меня подвергнуть сомнению мои средства, так как они казались действительными, но все же просто отображались обратно Я в том, что появилось действительный вывод.

Answer 4

Использовать регулярное выражение для удаления пробелов перед началом сравнения?