C#: Как проверить "не произошло никаких исключений" в моем модульном тесте?



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



Assert.IsTrue(????)


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



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

808   5  

5 ответов:

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

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

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

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

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

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

    }

Comments

    Ничего не найдено.