Assert.Inconclusive и IgnoreAttribute

Question

Как правильно использовать Assert.Inconclusive и IgnoreAttribute в рамках модульного тестирования MS?

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

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

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

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

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

Answer 1

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

• Inconclusive утверждения включены в отчет TRX, но mstest.exe (а также vstest.console.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(...);
}

_ _

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

• https://connect.microsoft.com/VisualStudio/feedback/details/779743/
• http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2088845

Answer 2

Мне нравится думать, что вы описываете 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 из задачи в моем скрипте msbuild, а затем заглядываю в TRX, чтобы определить, должен ли он произойти сбойсборка.

Answer 3

Начиная с документов MSDN:

1. IgnoreAttribute (начиная с VS 2005) означает " этот тест не должен выполняться " см. https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.ignoreattribute(v=vs.80).aspx.

2. Assert.Inconclusive (начиная с VS 2005) означает " Указывает, что утверждение не может быть подтверждено как истинное или ложное. Также используется для обозначения утверждения, которое не имеетеще реализовано."см. https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive(v=vs.80).aspx

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

Answer 4

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

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

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

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

Answer 5

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

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