Утверждение настроек и предварительных условий в модульных тестах

Question

Является ли наличие более одного утверждения на тест действительно неприятным запахом? Я обычно стараюсь следовать шаблону «аранжировать, действовать, утверждать», а также руководствоваться единым утверждением на тест Я думаю, что иметь чистые, маленькие, изолированные тесты - это просто потрясающе. По большей части мне удается это сделать. Тем не менее, иногда я начинаю утверждать «предварительные условия» сразу после моей аранжировки так:

'arrange:
'pre-conditions:     
     Assert the arrange worked
'act:
'assert:

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

Answer 1

Как я уже сказал здесь , я думаю, что, возможно, наша лучшая практика должна быть не Arrange-Act-Assert, а скорее Arrange- Предположим -Act-Assert. Что до принятия решения мы утверждаем, что желаемый результат действия еще не вступил в силу. Это не точно то же самое, что вы просите; как правило, я не думаю, что важно проверять настройку, потому что ошибки настройки проявляются довольно «громко» в любом случае; но это хорошая причина для второго утверждения в тесте.

Answer 2

Я бы не использовал для этого ванильный "Assert", а скорее Assert.Inconclusive (MSTest) ¹.Тест не прошел, поэтому вы не хотите проваливать тестовый прогон.

1) Предположим, в JUnit и NUnit, как я считаю.

Answer 3

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

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

Моя практика состоит в том, чтобы использовать Debug.Assert (в C #) для этой цели, чтобы проверка настроек не стала частью тестового вывода.

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

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