Лучший способ проверить исключения с Assert, чтобы они были брошены

Считаете ли вы, что это хороший способ тестирования исключений? Любые предложения?

Exception exception = null;
try{
    //I m sure that an exeption will happen here
}
catch (Exception ex){
    exception = ex;
}

Assert.IsNotNull(exception);

Я использую MS Test.

+73
12 апр. '09 в 0:12
источник поделиться
8 ответов

У меня есть несколько разных шаблонов, которые я использую. Я использую атрибут ExpectedException большую часть времени, когда ожидается исключение. Однако этого достаточно для большинства случаев, однако есть некоторые случаи, когда этого недостаточно. Исключение может не быть увлекательным - поскольку оно выбрасывается методом, вызываемым отражением, или, возможно, я просто хочу проверить, что другие условия сохранены, скажем, транзакция откат или какое-то значение еще установлено. В этих случаях я обертываю его в блок try/catch, который ожидает точное исключение, делает Assert.Fail, если код преуспевает, а также ловит общие исключения, чтобы убедиться, что другое исключение не выбрано.

Первый случай:

[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void MethodTest()
{
     var obj = new ClassRequiringNonNullParameter( null );
}

Второй случай:

[TestMethod]
public void MethodTest()
{
    try
    {
        var obj = new ClassRequiringNonNullParameter( null );
        Assert.Fail("An exception should have been thrown");
    }
    catch (ArgumentNullException ae)
    {
        Assert.AreEqual( "Parameter cannot be null or empty.", ae.Message );
    }
    catch (Exception e)
    {
        Assert.Fail(
             string.Format( "Unexpected exception of type {0} caught: {1}",
                            e.GetType(), e.Message )
        );
    }
}
+111
12 апр. '09 в 0:40
источник

Я новичок здесь и не имею репутации для комментариев или downvote, но хотел указать на недостаток в примере в Andy White answer:

try
{
    SomethingThatCausesAnException();
    Assert.Fail("Should have exceptioned above!");
}
catch (Exception ex)
{
    // whatever logging code
}

Во всех модулях модульного тестирования, с которыми я знаком, Assert.Fail работает, бросая исключение, поэтому общий catch фактически замаскирует отказ теста. Если SomethingThatCausesAnException() не выбрасывает, Assert.Fail будет, но это никогда не выскочит на тестовый бегун, чтобы показать сбой.

Если вам нужно поймать ожидаемое исключение (например, для утверждения определенных деталей, таких как сообщение/свойства для исключения), важно уловить определенный ожидаемый тип, а не базовый класс исключений. Это позволило бы исключить исключение Assert.Fail (при условии, что вы не выбрасываете тот же тип исключения, который существует в вашей инфраструктуре тестирования модулей), но все же допускают проверку исключения, которое было создано вашим методом SomethingThatCausesAnException().

+15
12 апр. '09 в 19:01
источник

Связанные вопросы


Похожие вопросы

По v 2.5, NUnit имеет следующий уровень уровня Assert для тестирования исключений:

Assert.Throws, который будет проверять для конкретного типа исключения:

Assert.Throws<NullReferenceException>(() => someNullObject.ToString());

И Assert.Catch, который будет проверять исключение данного типа или тип исключения, полученный из этого типа:

Assert.Catch<Exception>(() => someNullObject.ToString());

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

Edit

Чтобы привести пример комментария Matthew ниже, возвращение общих Assert.Throws и Assert.Catch является исключением с типом исключения, которое вы можете затем изучить для дальнейшего контроля:

// The type of ex is that of the generic type parameter (SqlException)
var ex = Assert.Throws<SqlException>(() => MethodWhichDeadlocks());
Assert.AreEqual(1205, ex.Number);
+12
25 окт. '13 в 11:33
источник

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

AssertThrowsException() принимает делегата и утверждает, что он генерирует ожидаемое исключение с ожидаемым сообщением.

AssertDoesNotThrowException() принимает тот же делегат и утверждает, что он не генерирует исключение.

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

Используя их, мой код unit test может выглядеть так:

ExceptionThrower callStartOp = delegate(){ testObj.StartOperation(); };

// Check exception is thrown correctly...
AssertThrowsException(callStartOp, typeof(InvalidOperationException), "StartOperation() called when not ready.");

testObj.Ready = true;

// Check exception is now not thrown...
AssertDoesNotThrowException(callStartOp);

Приятный и аккуратный ха?

Мои методы AssertThrowsException() и AssertDoesNotThrowException() определены в общем базовом классе следующим образом:

protected delegate void ExceptionThrower();

/// <summary>
/// Asserts that calling a method results in an exception of the stated type with the stated message.
/// </summary>
/// <param name="exceptionThrowingFunc">Delegate that calls the method to be tested.</param>
/// <param name="expectedExceptionType">The expected type of the exception, e.g. typeof(FormatException).</param>
/// <param name="expectedExceptionMessage">The expected exception message (or fragment of the whole message)</param>
protected void AssertThrowsException(ExceptionThrower exceptionThrowingFunc, Type expectedExceptionType, string expectedExceptionMessage)
{
    try
    {
        exceptionThrowingFunc();
        Assert.Fail("Call did not raise any exception, but one was expected.");
    }
    catch (NUnit.Framework.AssertionException)
    {
        // Ignore and rethrow NUnit exception
        throw;
    }
    catch (Exception ex)
    {
        Assert.IsInstanceOfType(expectedExceptionType, ex, "Exception raised was not the expected type.");
        Assert.IsTrue(ex.Message.Contains(expectedExceptionMessage), "Exception raised did not contain expected message. Expected=\"" + expectedExceptionMessage + "\", got \"" + ex.Message + "\"");
    }
}

/// <summary>
/// Asserts that calling a method does not throw an exception.
/// </summary>
/// <remarks>
/// This is typically only used in conjunction with <see cref="AssertThrowsException"/>. (e.g. once you have tested that an ExceptionThrower
/// method throws an exception then your test may fix the cause of the exception and then call this to make sure it is now fixed).
/// </remarks>
/// <param name="exceptionThrowingFunc">Delegate that calls the method to be tested.</param>
protected void AssertDoesNotThrowException(ExceptionThrower exceptionThrowingFunc)
{
    try
    {
        exceptionThrowingFunc();
    }
    catch (NUnit.Framework.AssertionException)
    {
        // Ignore and rethrow any NUnit exception
        throw;
    }
    catch (Exception ex)
    {
        Assert.Fail("Call raised an unexpected exception: " + ex.Message);
    }
}
+9
12 апр. '09 в 18:51
источник

К сожалению, MSTest STILL действительно имеет только атрибут ExpectedException (только показывает, сколько MS заботится о MSTest), который IMO довольно ужасен, потому что он разбивает шаблон Arrange/Act/Assert, и он не позволяет вам точно указать, какую строку кода вы хотите ожидать исключения.

Когда я использую (/принудительно клиентом) использовать MSTest, я всегда использую этот вспомогательный класс:

public static class AssertException
{
    public static void Throws<TException>(Action action) where TException : Exception
    {
        try
        {
            action();
        }
        catch (Exception ex)
        {
            Assert.IsTrue(ex.GetType() == typeof(TException), "Expected exception of type " + typeof(TException) + " but type of " + ex.GetType() + " was thrown instead.");
            return;
        }
        Assert.Fail("Expected exception of type " + typeof(TException) + " but no exception was thrown.");
    }

    public static void Throws<TException>(Action action, string expectedMessage) where TException : Exception
    {
        try
        {
            action();
        }
        catch (Exception ex)
        {
            Assert.IsTrue(ex.GetType() == typeof(TException), "Expected exception of type " + typeof(TException) + " but type of " + ex.GetType() + " was thrown instead.");
            Assert.AreEqual(expectedMessage, ex.Message, "Expected exception with a message of '" + expectedMessage + "' but exception with message of '" + ex.Message + "' was thrown instead.");
            return;
        }
        Assert.Fail("Expected exception of type " + typeof(TException) + " but no exception was thrown.");
    }
}

Пример использования:

AssertException.Throws<ArgumentNullException>(() => classUnderTest.GetCustomer(null));
+8
03 окт. '16 в 14:10
источник

Отметить тест с помощью атрибута ExpectedExceptionAttribute (это термин в NUnit или MSTest, пользователям могут потребоваться переводы других структурных модулей тестирования).

+4
12 апр. '09 в 0:17
источник

Теперь, 2017, вы можете сделать это проще с новой MSTest V2 Framework:

Assert.ThrowsException<Exception>(() => myClass.MyMethodWithError());
+3
07 мая '17 в 0:19
источник

С большинством .net модульных модулей тестирования вы можете поместить атрибут [ExpectedException] в методе тестирования. Однако это не может сказать вам, что исключение произошло в тот момент, когда вы ожидали этого. Это может помочь xunit.net.

С xunit у вас есть Assert.Throws, поэтому вы можете делать такие вещи:

    [Fact]
    public void CantDecrementBasketLineQuantityBelowZero()
    {
        var o = new Basket();
        var p = new Product {Id = 1, NetPrice = 23.45m};
        o.AddProduct(p, 1);
        Assert.Throws<BusinessException>(() => o.SetProductQuantity(p, -3));
    }

[Факт] - это xunit-эквивалент [TestMethod]

+2
12 апр. '09 в 0:17
источник

Посмотрите другие вопросы по меткам или Задайте вопрос