Сообщения подтверждения: предполагаем неудачу или предполагаем успех - PullRequest
10 голосов
/ 20 декабря 2008

При тестировании на любом языке, как все формулируют свои сообщения подтверждения ?

Я вижу три очевидных пути:

# assume failure
assert (4-2) == 2, "Subtracting 2 from 4 doesn't equal 2"

# describe success
assert (4-2) == 2, "Subtracting 2 from 4 should equal 2"

# be vauge with failure
assert (4-2) == 2, "Subtracting 2 from 4 is broken"

Это, очевидно, простой пример, но вы поняли идею. Какова стандартная практика? Чем ты занимаешься? Почему?

Ответы [ 7 ]

7 голосов
/ 20 декабря 2008

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

"Substracting 2 from 4 should equal 2, but equals " + value

Это не оставляет места для сомнений и облегчает отладку.

3 голосов
/ 20 декабря 2008

Важным моментом утверждения является фактическое тестируемое условие. В C вы можете использовать препроцессор «stringization» для вывода фактического состояния, которое тестируется. Мой код просто выводит

Assert Failed: (4-2)==2 : Line 123, File foo.c

Если вам повезет, вы также можете получить дамп стека ...

2 голосов
/ 20 декабря 2008

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

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

2 голосов
/ 20 декабря 2008

Я не знаю, есть ли какой-нибудь "стандарт", но в большинстве случаев мне нравится видеть само условие утверждения. С делает это автоматически. В C # я должен скопировать и вставить его, к сожалению, например.

Debug.Assert(4-2==2, "4-2==2");

В некоторых случаях полезно видеть больше информации, чем предоставляет условие. В этом случае я рассматриваю сообщение assert как сообщение об ошибке и указываю, что не так, например.

Debug.Assert(result != null, "No result returned for input '" + input + "'");

1 голос
/ 20 декабря 2008

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

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

1 голос
/ 20 декабря 2008

Предложение Родди является хорошим - оно, безусловно, удешевляет «добавление» новых утверждений (то есть не требует обдумывания или ввода нового строкового сообщения). Хотите верьте, хотите нет, но реализация его предложения оказала значительное влияние на мое использование утверждений.

Если вы все еще ищете более четкое текстовое сообщение, вы можете рассмотреть что-то вроде:

"Ожидается, что 4-2 будет равно 2"

Кажется, это ясно (по крайней мере, мне), что ожидаемый ответ был 2, но ожидание не было выполнено ...

1 голос
/ 20 декабря 2008

Это действительно не имеет значения IMO, пока сообщение об ошибке говорит вам, что пошло не так и где проблема. При нормальной работе сообщение подтверждения никогда не будет видно. Если это замечено, то где-то есть ошибка в коде, и вы должны быть в состоянии отследить и исправить ошибку.

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

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