Il modo migliore per testare le eccezioni con Assert per assicurarsi che vengano lanciate

Pensi che questo sia un buon modo per testare le eccezioni? Eventuali suggerimenti?

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

Assert.IsNotNull(exception);

Sto usando MS Test.

Ho un paio di modelli diversi che uso. Uso l' ExpectedExceptionattributo la maggior parte delle volte quando è prevista un'eccezione. Ciò è sufficiente per la maggior parte dei casi, tuttavia, in alcuni casi ciò non è sufficiente. L'eccezione potrebbe non essere catturabile, poiché viene lanciata da un metodo invocato per riflessione, o forse voglio solo verificare che siano presenti altre condizioni, ad esempio una transazione viene annullata o un valore è ancora stato impostato. In questi casi lo racchiudo in un try/catchblocco che si aspetta l'eccezione esatta, esegue un'eccezione Assert.Failse il codice ha esito positivo e rileva anche eccezioni generiche per assicurarsi che non venga generata un'eccezione diversa.

Primo caso:

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

Secondo caso:

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

Ora, 2017, puoi farlo più facilmente con il nuovo MSTest V2 Framework :

Assert.ThrowsException<Exception>(() => myClass.MyMethodWithError());

//async version
await Assert.ThrowsExceptionAsync<SomeException>(
  () => myObject.SomeMethodAsync()
);

Sono nuovo qui e non ho la reputazione di commentare o votare in negativo, ma volevo sottolineare un difetto nell'esempio nella risposta di Andy White :

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

In tutti i framework di unit test che conosco, Assert.Failfunziona generando un'eccezione, quindi il catch generico maschererà effettivamente il fallimento del test. Se SomethingThatCausesAnException()non lancia, la Assert.Failvolontà, ma questo non verrà mai fuoriuscire dal test runner per indicare il fallimento.

Se è necessario catturare l'eccezione attesa (cioè, per affermare determinati dettagli, come il messaggio / le proprietà sull'eccezione), è importante catturare il tipo atteso specifico e non la classe di eccezione di base. Ciò consentirebbe la Assert.Failfuoriuscita dell'eccezione (supponendo che non si stia generando lo stesso tipo di eccezione del framework di unit test), ma consentire comunque la convalida sull'eccezione generata dal SomethingThatCausesAnException()metodo.

A partire dalla v 2.5, NUnit ha i seguenti livelli di metodo Assertper testare le eccezioni:

Assert.Throws , che testerà un tipo di eccezione esatto:

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

E Assert.Catch, che testerà un'eccezione di un determinato tipo o un tipo di eccezione derivato da questo tipo:

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

Per inciso, durante il debug di unit test che generano eccezioni, potresti voler impedire a VS di interrompere l'eccezione .

modificare

Giusto per fare un esempio del commento di Matteo di seguito, il ritorno del generico Assert.Throwsed Assert.Catchè l'eccezione con il tipo di eccezione, che puoi poi esaminare per un ulteriore controllo:

// The type of ex is that of the generic type parameter (SqlException)
var ex = Assert.Throws<SqlException>(() => MethodWhichDeadlocks());
Assert.AreEqual(1205, ex.Number);

Sfortunatamente MSTest ANCORA ha davvero solo l'attributo ExpectedException (mostra solo quanto MS si preoccupa di MSTest) che IMO è piuttosto orribile perché rompe il modello Arrange / Act / Assert e non ti consente di specificare esattamente quale riga di codice ti aspetti l'eccezione a verificarsi.

Quando utilizzo (/ costretto da un client) per utilizzare MSTest, utilizzo sempre questa classe di supporto:

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.");
    }
}

Esempio di utilizzo:

AssertException.Throws<ArgumentNullException>(() => classUnderTest.GetCustomer(null));

In alternativa all'utilizzo di ExpectedExceptionattributi, a volte definisco due metodi utili per le mie classi di test:

AssertThrowsException() accetta un delegato e afferma che genera l'eccezione prevista con il messaggio previsto.

AssertDoesNotThrowException() accetta lo stesso delegato e afferma che non genera un'eccezione.

Questa associazione può essere molto utile quando si desidera verificare che un'eccezione venga generata in un caso, ma non nell'altro.

Usandoli il mio codice di unit test potrebbe essere simile a questo:

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

Bello e pulito eh?

My AssertThrowsException()e AssertDoesNotThrowException()metodi sono definiti su una classe base comune come segue:

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

Contrassegnare il test con ExpectedExceptionAttribute (questo è il termine in NUnit o MSTest; gli utenti di altri framework di unit test potrebbero dover tradurre).

Con la maggior parte dei framework di unit test .net è possibile inserire un attributo [ExpectedException] nel metodo di test. Tuttavia, questo non può dirti che l'eccezione è avvenuta nel punto in cui ti aspettavi. È qui che xunit.net può aiutarti.

Con xunit hai Assert.Throws, quindi puoi fare cose come questa:

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

[Fact] è l'equivalente xunit di [TestMethod]

Suggerire di utilizzare la sintassi del delegato pulito di NUnit .

Esempio per il test ArgumentNullExeption:

[Test]
[TestCase(null)]
public void FooCalculation_InvalidInput_ShouldThrowArgumentNullExeption(string text)
{
    var foo = new Foo();
    Assert.That(() => foo.Calculate(text), Throws.ArgumentNullExeption);

    //Or:
    Assert.That(() => foo.Calculate(text), Throws.Exception.TypeOf<ArgumentNullExeption>);
}