Что делает хорошее сообщение об ошибке для testunit или других структур стиля nunit?

Question

В тесте / модуле Руби и других подобных структурах стиля nunit, что делает хорошее сообщение об ошибке?

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

assert_match("hey", "hey this is a test", "The word does not exist in the string")

Должно ли оно описывать то, что вы ожидали?

assert_match("hey", "hey this is a test", "I expected hey to be in the string")

Должно ли оно описывать, почему вы хотели, чтобы это произошло?

assert_match("hey", "hey this is a test", "Program should provide a greeting")

Должно ли оно описывать, почему вы думали, чтоможет произойти сбой теста?

assert_match("konnichiwa", "konnichiwa this is a test",
  "Program failed to use supplied i18n configuration")

Должна ли информация о тестах существовать и в названии метода теста, и в названии теста?

Это основано на Ruby"test / unit", как отобразить сообщения в утверждениях

Answer 1

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

Поэтому, если набор [имя метода, ожидаемый, фактический] подходит для вышеуказанной цели, вы можете пропустить сообщение об ошибке.Если вам нужна дополнительная информация, то вы добавляете дополнительное сообщение об ошибке.

например, Expected true but was false, ничего мне не говорит.

Вы можете использовать сообщение об ошибке, чтобы Return value should contain only multiples of 10. Expected true but was false

Сначала вы можете попытаться использовать более описательные сопоставления.Так что сбои чтения Expected all items to be divisible by 10 but was [10,20,35,40] делает.

Лично я предпочитаю совпадения ... используйте сообщения об ошибках как последнее средство.(потому что, как и комментарии, он исчезает. Вам нужно соблюдать дисциплину, чтобы обновлять сообщение об ошибке, если вы измените проверку.)