Assert.Inconclusive и IgnoreAttribute

Каков правильный способ использования Assert.Inconclusive и IgnoreAttribute в MS Unit test framework?

Мы используем Assert.Inconclusive в основном для тестов, которые:

  • Не реализовано.
  • Как-то сломанный или неполный = требуется более пристальное внимание
  • Когда тестовое тело по какой-либо причине прокомментировано

Мы делаем это, потому что:

  • Неконвертируемый тест может содержать сообщение
  • Мы хотим увидеть такие тесты в результатах тестирования на TFS

Наша проблема заключается в том, что тесты Inconclusive помечены как ошибка как в TFS, так и в Resharper. Если мы будем использовать IgnoreAttribute, мы увидим эти тесты в Resharper, но MS Test runner и TFS проигнорируют их вообще. Использование IgnoreAttribute в TFS и MS Test runner аналогично комментированию всего теста, который бесполезен.

ОТВЕТЫ

Ответ 1

Мне нравится думать, как вы описываете Inconclusive - это правильное использование.

Хотя по моему опыту, Inconclusive воспринимается скорее как предупреждение, чем ошибка. Фактически, они сообщаются в TRX отдельно от ошибок:

<TestRun>
   <ResultSummary outcome="Inconclusive">
      <Counters total="1" 
          executed="0" error="0" failed="0" 
          timeout="0" aborted="0" inconclusive="1" 
          passedButRunAborted="0" notRunnable="0" 
          notExecuted="0" disconnected="0" 
          warning="0" passed="0" completed="0" 
          inProgress="0" pending="0" />

Я обычно запускаю исполняемый файл mstest из <Exec> задайте в моей msbuild script, а затем загляните внутрь TRX, чтобы определить, не следует ли выполнить сборку.

Ответ 2

Я также вижу дилемму в текущей реализации.

  • Inconclusive утверждения включаются в отчет TRX, но mstest.exe вернет 1 (что означает ошибка) после выполнения.
  • TestMethods с атрибутом Ignore не будет отображаться как ошибка, но они полностью скрыты из отчета TRX.

мое личное понимание таково:

используйте атрибут [Ignore] для (временно) отключения/пропустить метод:

[TestMethod]
[Ignore] // <== disabled through "Ignore" attribute
public void Test001()
{
   //execute some stuff ...
   Assert.IsTrue(...);

   //execute some stuff ...
   Assert.AreEqual(...);
}

do не неправильно использовать утверждение Inconclusive для этой цели:

[TestMethod]
public void Test002()
{
    Assert.Inconclusive(); // <== misuse of "Inconclusive" to skip this test

    //execute some stuff ...
}

вместо этого Inconclusive следует использовать условно: только если мы не можем определить, будет ли тестируемый компонент работать должным образом или нет.
например, если внешний ресурс, от которого мы зависим, недоступен во время выполнения теста:

[TestMethod]
public void Test003()
{
    //check if the server is running,
    //otherwise can can't test our local client component!
    if (!WebServiceAvailable())
    {
        Assert.Inconclusive(); // <== skip remaining code because the resource is not available
    }

    //execute some stuff ...
    Assert.AreEqual(...);

    //execute some stuff ...
    Assert.AreEqual(...);
}

_ _

Вывод:
чтобы отключить/пропустить тест, логичным способом является использование атрибута [Ignore].
я отчетливо вижу, что текущее поведение mstest.exe не сообщается ни о каком проигнорированном тесте, как об ошибке , которая должна быть исправлена.

не стесняйтесь проголосовать за следующие отчеты об ошибках:

Ответ 3

Я занимаюсь некоторыми исследованиями в этом, а также проверял его дома. В результате я считаю, что атрибут [Игнорировать] для MSTest действительно полностью исключает метод тестирования. Я попытался посмотреть настройки в Visual Studio, чтобы узнать, есть ли переопределение, но ничего не нашел.

Позор по этому поводу, так как не видно, что проигнорированные тесты плохи, так как вы можете подумать, что у вас есть набор из 100 тестов MSTest, которые работают хорошо, но оказывается, что есть 50, которые отсутствуют из результатов, которые вы никогда не знали из-за атрибута [Ignore]! Urgh.

Ответ 4

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

Чтобы протестировать определенные функции, система, находящаяся под тестированием (SUT), сначала должна быть переведена в определенное состояние. Как только это состояние будет достигнуто, тест может фактически проверить функцию, для которой он предназначен. Теперь, каков должен быть статус такого теста, если уже часть установки не работает. Он не может сделать выражение о функционировании тестируемой функции, так как тест, никогда не достигнутый, требует выполнения функции.

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

Итак, представьте, я хочу проверить, что "foo", который был "bar'ed, вернет 0, когда" qux'ed. Этот тест не должен проверяться, если "foo" может быть "bar", поэтому любой отказ от "bar'ed" вернет неубедительный результат, тогда как отказ от ответа на "qux" будет неудачным.

Ответ 5

Как и в документах MSDN:

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