Как проверить, что «исключений не было» в модульном тесте MSTest?

Я пишу модульный тест для этого единственного метода, который возвращает «void». Я хотел бы иметь один случай, когда тест проходит, когда нет исключения. Как мне написать это на C #?

Assert.IsTrue(????)

(Я предполагаю, что именно так я должен проверить, но что входит в "???")

Надеюсь, мой вопрос достаточно ясен.

Ваш модульный тест в любом случае не сработает, если будет выбрано исключение - вам не нужно вводить специальное утверждение.

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

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

[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)

В NUnit вы можете использовать:

Assert.DoesNotThrow(<expression>); 

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

Я считаю правильным добавлять тесты, чтобы гарантировать, что ваш код не генерирует исключения; например, представьте, что вы проверяете ввод и вам нужно преобразовать входящую строку в длинную. Могут быть случаи, когда строка имеет значение NULL, и это приемлемо, поэтому вы хотите убедиться, что преобразование строки не вызовет исключения. Следовательно, будет код для обработки этого случая, и если вы не написали для него тест, вам будет не хватать покрытия вокруг важной части логики.

Не проверяйте, что чего-то не происходит . Это похоже на гарантию того, что код не сломается . Это как бы подразумевает, что все мы стремимся к неразрывному и безошибочному коду. Вы хотите написать для этого тесты? Почему только один метод? Разве вы не хотите, чтобы все ваши методы проверялись и не вызывали исключения ? Следуя по этому пути, вы получите один дополнительный фиктивный тест без утверждений для каждого метода в вашей базе кода. Это не приносит никакой ценности.

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

Однако общий подход / практика остаются неизменными - вы не пишете тесты для некоторых искусственных / расплывчатых требований, которые выходят за рамки тестируемого кода (и проверка того, что «работает» или «не работает», обычно является примером такие - особенно в сценарии, когда обязанности метода хорошо известны).

Проще говоря - сосредоточьтесь на том, что должен делать ваш код , и проверьте это.

Этот вспомогательный класс почесал мне зуд с помощью 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);
        }
    }
}

Мне нравится видеть 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

    }

Мой друг Тим рассказал мне об ExpectedException . Мне очень нравится этот b / c, он более лаконичный, меньше кода и очень ясно, что вы тестируете исключение.

[TestMethod()]
[ExpectedException(typeof(System.Exception))]
public void DivideTest()
{
    int numerator = 4;
    int denominator = 0;
    int actual = numerator / denominator;
}

Подробнее об этом можно прочитать здесь: Использование атрибута ExpectedException .