Проверка не удалась в FitNesse, и я не вижу разницы между ожидаемым и фактическим - PullRequest
3 голосов
/ 11 января 2012

Я использую FitNesse для тестирования ответов веб-службы, используя 'check', чтобы сравнить ожидаемый с фактическим ответом; в некоторых случаях проверка не проходит, и я не вижу разницы между ожидаемым и фактическим, что приводит к сбою.

Вот снимок экрана с тем, что он говорит мне в конкретном случае (из многих подобных случаев); Кто-нибудь может определить, почему он не прошел проверку?

Here's an example where it's failing and I can't see why

Не стесняйтесь указывать на очевидное; это, вероятно, смотрит на меня в лицо, и я смотрю так сильно, что я не вижу этого!

Спасибо

Ответы [ 4 ]

1 голос
/ 24 апреля 2014

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

0 голосов
/ 01 июля 2016

Пробелы часто беспокоили меня. Получающийся HTML просто сворачивает пробел, но сравнение в коде - нет. Теперь я использую прибор, чтобы сделать различия более явными для меня. Пример использования: http://fhoeben.github.io/hsac-fitnesse-fixtures/examples-results/HsacExamples.SlimTests.UtilityFixtures.CompareFixtureTest.html

В более новых версиях FitNesse (с 20151230) проводится анализ ожидаемых и фактических значений результатов Вам это вообще помогло?

0 голосов
/ 03 сентября 2014

В этом вопросе не указывается, используются ли Slim или Fit, или какой сервер / плагин Slim, если используется Slim, но я обнаружил, что для меня верно следующее использование выпуска FitNesse 20130530 и выпуска fitSharp 2,2

  1. Не входящие в ASCII символы и символы {апострофы / одинарные кавычки} во входных аргументах / параметрах, которые являются строками, кодируются в формате HTML. Значения в моих тестовых таблицах FitNesse имеют кодировку HTML, но только необходимые синтаксические символы и (двойные) кавычки; не символы не ASCII (и у FitNesse, похоже, нет проблем с хранением этих значений).
  2. Символы EOL во входных аргументах, которые являются строками, состоят только из символа перевода строки
  3. Я предполагаю, что, поскольку я использую .NET, EOL в возвращаемых значениях состоят из символов возврата каретки и перевода строки.

Из-за [1] я кодирую HTML не-ASCII-символами (но не синтаксическими символами HTML или кавычками). Из-за [2] и [3] я теперь удаляю символы возврата каретки из возвращаемых значений моего прибора. Похоже, что оба изменения решили эту проблему для меня, и ожидаемые и фактические значения теперь сообщаются как одинаковые.

0 голосов
/ 12 января 2012

Возможно, ваша строка содержит лишние пробелы в фактическом значении. FitNesse, основанный на html, не будет учитывать начальные или конечные пробелы. Это может не обрабатывать лишние пробелы внутри фактического либо. Так что это может привести к тому, что результат будет другим, но не так заметно.

Посмотрите, можете ли вы добавить несколько сообщений отладки, которые помогут вам увидеть лишние пробелы или, по крайней мере, подсчитать количество символов в обеих строках.

...