С#: Как я могу проверить "не произошло исключение" в моем модульном тесте MSTest?
Я пишу unit test для этого метода, который возвращает "void". Я хотел бы иметь один случай, когда тест проходит, когда нет исключения. Как написать это в С#?
Assert.IsTrue(????)
(Мое предположение - это то, как я должен проверять, но что происходит в "???" )
Надеюсь, мой вопрос достаточно ясен.
Ответы
Ответ 1
В противном случае ваш unit test будет терпеть неудачу, если будет создано исключение - вам не нужно вводить специальное утверждение.
Это один из немногих сценариев, в которых вы увидите модульные тесты без каких-либо утверждений - тест будет неявно сбой при возникновении исключения.
Однако, если вы действительно хотите написать утверждение для этого - возможно, чтобы уловить исключение и сообщить "ожидаемое исключение, но получившее это...", вы можете сделать это:
[Test]
public void TestNoExceptionIsThrownByMethodUnderTest()
{
var myObject = new MyObject();
try
{
myObject.MethodUnderTest();
}
catch (Exception ex)
{
Assert.Fail("Expected no exception, but got: " + ex.Message);
}
}
(приведенный выше пример NUnit, но то же самое верно для MSTest)
Ответ 2
В NUnit вы можете использовать:
Assert.DoesNotThrow(<expression>);
чтобы утверждать, что ваш код не генерирует исключение. Несмотря на то, что тест завершился неудачей, если исключение было выброшено, даже если в нем не было утверждений, значение этого подхода заключается в том, что тогда вы можете различать неудовлетворенные ожидания и ошибки в своих тестах, и у вас есть возможность добавить настраиваемое сообщение, будет отображаться на вашем тестовом выходе. Выделенный тестовый результат может помочь вам обнаружить ошибки в коде, вызвавшие провал теста.
Я считаю правильным добавить тесты, чтобы убедиться, что ваш код не выбрасывает исключения; например, представьте, что вы проверяете ввод и нужно преобразовать входящую строку в длинную. Могут быть случаи, когда строка имеет значение NULL, и это приемлемо, поэтому вы хотите убедиться, что преобразование строк не вызывает исключения. Поэтому для этого случая должен быть код, и если вы не написали тест на него, вам не хватит покрытия вокруг важной части логики.
Ответ 3
Не тестируйте, что что-то не происходит. Это похоже на то, что код не сломается. Такого рода подразумеваемые, мы все стремимся к неразрывному, без ошибок коде. Вы хотите написать тесты для этого? Почему только один метод? Разве вы не хотите, чтобы все ваши методы проверялись, чтобы они не бросали какое-то исключение? После этой дороги вы получите один дополнительный, фиктивный, безрезультатный тест для каждого метода в базе кода. Это не приносит никакой ценности.
Конечно, если ваше требование состоит в проверке исключений catch делает, вы проверяете это (или немного меняете его, проверяете, чтобы он не бросал то, что он должен ловить).
Однако общий подход/практика остаются неповрежденными - вы не пишете тесты на некоторые искусственные/неопределенные требования, выходящие за рамки тестируемого кода (и тестирование, которое "оно работает" или "не бросает", обычно пример такого - особенно в сценарии, когда функции метода хорошо известны).
Проще говоря, сосредоточьтесь на том, что должен сделать ваш .
Ответ 4
Этот класс-помощник поцарапал мой зуд с помощью MSTest. Возможно, это может поцарапать и вас.
[TestMethod]
public void ScheduleItsIneligibilityJob_HasValid_CronSchedule()
{
// Arrange
var factory = new StdSchedulerFactory();
IScheduler scheduler = factory.GetScheduler();
// Assert
AssertEx.NoExceptionThrown<FormatException>(() =>
// Act
_service.ScheduleJob(scheduler)
);
}
public sealed class AssertEx
{
public static void NoExceptionThrown<T>(Action a) where T:Exception
{
try
{
a();
}
catch (T)
{
Assert.Fail("Expected no {0} to be thrown", typeof(T).Name);
}
}
}
Ответ 5
Мне нравится видеть Assert.Whatever
в конце каждого теста, просто для согласованности... без него, могу ли я быть уверен, что там не должно быть там?
Для меня это так же просто, как положить Assert.IsTrue(true);
Я знаю, что я случайно не включил этот код, и поэтому я должен быть достаточно уверенным в том, чтобы быстро пропустить это, как предполагалось.
[TestMethod]
public void ProjectRejectsGappedVersioningByDefault() {
var files = new List<ScriptFile>();
files.Add(ScriptProjectTestMocks.GetVersion1to2());
files.Add(ScriptProjectTestMocks.GetVersion3to4());
Assert.Throws<ScriptProject.InvalidProjectFormatException>(() => {
var sut = new ScriptProject(files);
});
}
[TestMethod]
public void ProjectAcceptsGappedVersionsExplicitly() {
var files = new List<ScriptFile>();
files.Add(ScriptProjectTestMocks.GetVersion1to2());
files.Add(ScriptProjectTestMocks.GetVersion3to4());
var sut = new ScriptProject(files, true);
Assert.IsTrue(true); // Assert.Pass() would be nicer... build it in if you like
}