Comment utiliser Assert pour vérifier qu'une exception a été levée?

Comment utiliser Assert(ou une autre classe de test?) Pour vérifier qu'une exception a été levée?

Pour "Visual Studio Team Test", il apparaît que vous appliquez l'attribut ExpectedException à la méthode du test.

Exemple de documentation ici: Procédure pas à pas de test unitaire avec Visual Studio Team Test

[TestMethod]
[ExpectedException(typeof(ArgumentException),
    "A userId of null was inappropriately allowed.")]
public void NullUserIdInConstructor()
{
   LogonInfo logonInfo = new LogonInfo(null, "P@ss0word");
}

Habituellement, votre framework de test aura une réponse à cela. Mais si ce n'est pas assez flexible, vous pouvez toujours le faire:

try {
    somethingThatShouldThrowAnException();
    Assert.Fail(); // If it gets to this line, no exception was thrown
} catch (GoodException) { }

Comme le souligne @Jonas, cela ne fonctionne PAS pour intercepter une exception de base:

try {
    somethingThatShouldThrowAnException();
    Assert.Fail(); // raises AssertionException
} catch (Exception) {
    // Catches the assertion exception, and the test passes
}

Si vous devez absolument attraper Exception, vous devez relancer Assert.Fail (). Mais vraiment, c'est un signe que vous ne devriez pas écrire cela à la main; vérifiez votre framework de test pour les options, ou voyez si vous pouvez lever une exception plus significative à tester.

catch (AssertionException) { throw; }

Vous devriez être en mesure d'adapter cette approche à tout ce que vous voulez, notamment en spécifiant les types d'exceptions à intercepter. Si vous ne vous attendez qu'à certains types, terminez les catchblocs avec:

} catch (GoodException) {
} catch (Exception) {
    // not the right kind of exception
    Assert.Fail();
}

Ma méthode préférée pour implémenter cela est d'écrire une méthode appelée Throws et de l'utiliser comme n'importe quelle autre méthode Assert. Malheureusement, .NET ne vous permet pas d'écrire une méthode d'extension statique, vous ne pouvez donc pas utiliser cette méthode comme si elle appartenait réellement à la génération dans la classe Assert; faites simplement un autre appelé MyAssert ou quelque chose de similaire. La classe ressemble à ceci:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace YourProject.Tests
{
    public static class MyAssert
    {
        public static void Throws<T>( Action func ) where T : Exception
        {
            var exceptionThrown = false;
            try
            {
                func.Invoke();
            }
            catch ( T )
            {
                exceptionThrown = true;
            }

            if ( !exceptionThrown )
            {
                throw new AssertFailedException(
                    String.Format("An exception of type {0} was expected, but not thrown", typeof(T))
                    );
            }
        }
    }
}

Cela signifie que votre test unitaire ressemble à ceci:

[TestMethod()]
public void ExceptionTest()
{
    String testStr = null;
    MyAssert.Throws<NullReferenceException>(() => testStr.ToUpper());
}

Qui ressemble et se comporte beaucoup plus comme le reste de vos syntaxes de test unitaire.

si vous utilisez NUNIT, vous pouvez faire quelque chose comme ceci:

Assert.Throws<ExpectedException>(() => methodToTest());

Il est également possible de stocker l'exception levée afin de la valider davantage:

ExpectedException ex = Assert.Throws<ExpectedException>(() => methodToTest());
Assert.AreEqual( "Expected message text.", ex.Message );
Assert.AreEqual( 5, ex.SomeNumber);

Voir: http://nunit.org/docs/2.5/exceptionAsserts.html

Si vous utilisez MSTest, qui à l'origine n'avait pas d' ExpectedExceptionattribut, vous pouvez le faire:

try 
{
    SomeExceptionThrowingMethod()
    Assert.Fail("no exception thrown");
}
catch (Exception ex)
{
    Assert.IsTrue(ex is SpecificExceptionType);
}

Méfiez-vous de l'utilisation d'ExpectedException, car cela peut entraîner plusieurs pièges, comme illustré ici:

http://geekswithblogs.net/sdorman/archive/2009/01/17/unit-testing-and-expected-exceptions.aspx

Et ici:

http://xunit.github.io/docs/comparisons.html

Si vous avez besoin de tester les exceptions, il existe moins de moyens désapprouvés. Vous pouvez utiliser la méthode try {act / fail} catch {assert}, qui peut être utile pour les frameworks qui ne prennent pas directement en charge les tests d'exception autres que ExpectedException.

Une meilleure alternative consiste à utiliser xUnit.NET, qui est un cadre de test unitaire très moderne, prospectif et extensible qui a appris de toutes les autres erreurs et s'est amélioré. Une telle amélioration est Assert.Throws, qui fournit une bien meilleure syntaxe pour affirmer des exceptions.

Vous pouvez trouver xUnit.NET sur github: http://xunit.github.io/

MSTest (v2) a maintenant une fonction Assert.ThrowsException qui peut être utilisée comme ceci:

Assert.ThrowsException<System.FormatException>(() =>
            {
                Story actual = PersonalSite.Services.Content.ExtractHeader(String.Empty);
            }); 

Vous pouvez l'installer avec nuget: Install-Package MSTest.TestFramework

Dans un projet sur lequel je travaille, nous avons une autre solution pour cela.

Tout d'abord, je n'aime pas le ExpectedExceptionAttribute car il prend en considération l'appel de méthode qui a provoqué l'exception.

Je fais cela avec une méthode d'aide à la place.

Tester

[TestMethod]
public void AccountRepository_ThrowsExceptionIfFileisCorrupt()
{
     var file = File.Create("Accounts.bin");
     file.WriteByte(1);
     file.Close();

     IAccountRepository repo = new FileAccountRepository();
     TestHelpers.AssertThrows<SerializationException>(()=>repo.GetAll());            
}

HelperMethod

public static TException AssertThrows<TException>(Action action) where TException : Exception
    {
        try
        {
            action();
        }
        catch (TException ex)
        {
            return ex;
        }
        Assert.Fail("Expected exception was not thrown");

        return null;
    }

Neat, n'est-ce pas;)

C'est un attribut de la méthode de test ... vous n'utilisez pas Assert. Ressemble à ça:

[ExpectedException(typeof(ExceptionType))]
public void YourMethod_should_throw_exception()

Vous pouvez télécharger un package à partir de Nuget à l'aide de: PM> Install-Package MSTestExtensions qui ajoute la syntaxe Assert.Throws () dans le style nUnit / xUnit à MsTest.

Instructions de haut niveau: téléchargez l'assembly et héritez de BaseTest et vous pouvez utiliser la syntaxe Assert.Throws () .

La méthode principale pour l'implémentation de Throws se présente comme suit:

public static void Throws<T>(Action task, string expectedMessage, ExceptionMessageCompareOptions options) where T : Exception
{
    try
    {
        task();
    }
    catch (Exception ex)
    {
        AssertExceptionType<T>(ex);
        AssertExceptionMessage(ex, expectedMessage, options);
        return;
    }

    if (typeof(T).Equals(new Exception().GetType()))
    {
        Assert.Fail("Expected exception but no exception was thrown.");
    }
    else
    {
        Assert.Fail(string.Format("Expected exception of type {0} but no exception was thrown.", typeof(T)));
    }
}

Divulgation: J'ai mis en place ce package.

Plus d'informations: http://www.bradoncode.com/blog/2012/01/asserting-exceptions-in-mstest-with.html

Vous pouvez y parvenir avec une simple ligne.

Si votre opération foo.bar()est asynchrone:

await Assert.ThrowsExceptionAsync<Exception>(() => foo.bar());

Si foo.bar()n'est pas asynchrone

Assert.ThrowsException<Exception>(() => foo.bar());

Je ne recommande pas d'utiliser l'attribut ExpectedException (car il est trop contraignant et sujet aux erreurs) ou d'écrire un bloc try / catch dans chaque test (car il est trop compliqué et sujet aux erreurs). Utilisez une méthode d'assertion bien conçue - fournie par votre framework de test ou écrivez la vôtre. Voici ce que j'ai écrit et utilisé.

public static class ExceptionAssert
{
    private static T GetException<T>(Action action, string message="") where T : Exception
    {
        try
        {
            action();
        }
        catch (T exception)
        {
            return exception;
        }
        throw new AssertFailedException("Expected exception " + typeof(T).FullName + ", but none was propagated.  " + message);
    }

    public static void Propagates<T>(Action action) where T : Exception
    {
        Propagates<T>(action, "");
    }

    public static void Propagates<T>(Action action, string message) where T : Exception
    {
        GetException<T>(action, message);
    }

    public static void Propagates<T>(Action action, Action<T> validation) where T : Exception
    {
        Propagates(action, validation, "");
    }

    public static void Propagates<T>(Action action, Action<T> validation, string message) where T : Exception
    {
        validation(GetException<T>(action, message));
    }
}

Exemple utilise:

    [TestMethod]
    public void Run_PropagatesWin32Exception_ForInvalidExeFile()
    {
        (test setup that might propagate Win32Exception)
        ExceptionAssert.Propagates<Win32Exception>(
            () => CommandExecutionUtil.Run(Assembly.GetExecutingAssembly().Location, new string[0]));
        (more asserts or something)
    }

    [TestMethod]
    public void Run_PropagatesFileNotFoundException_ForExecutableNotFound()
    {
        (test setup that might propagate FileNotFoundException)
        ExceptionAssert.Propagates<FileNotFoundException>(
            () => CommandExecutionUtil.Run("NotThere.exe", new string[0]),
            e => StringAssert.Contains(e.Message, "NotThere.exe"));
        (more asserts or something)
    }

REMARQUES

Renvoyer l'exception au lieu de prendre en charge un rappel de validation est une idée raisonnable, sauf que cela rend la syntaxe d'appel de cette assertion très différente de celle des autres assertions que j'utilise.

Contrairement à d'autres, j'utilise «propage» au lieu de «lancers» car nous ne pouvons tester que si une exception se propage à partir d'un appel. Nous ne pouvons pas tester directement qu'une exception est levée. Mais je suppose que vous pourriez dire que les lancers d'images sont: lancés et non attrapés.

PENSÉE FINALE

Avant de passer à ce type d'approche, j'ai envisagé d'utiliser l'attribut ExpectedException lorsqu'un test ne vérifiait que le type d'exception et d'utiliser un bloc try / catch si une validation supplémentaire était requise. Mais, non seulement je devrais réfléchir à la technique à utiliser pour chaque test, mais changer le code d'une technique à l'autre en fonction des besoins n'était pas un effort trivial. L'utilisation d'une approche cohérente économise l'effort mental.

Donc en résumé, cette approche sportive: facilité d'utilisation, flexibilité et robustesse (difficile de se tromper).

L'assistant fourni par @Richiban ci-dessus fonctionne très bien, sauf qu'il ne gère pas la situation où une exception est levée, mais pas le type attendu. Les réponses suivantes:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace YourProject.Tests
{
    public static class MyAssert
    {
        /// <summary>
        /// Helper for Asserting that a function throws an exception of a particular type.
        /// </summary>
        public static void Throws<T>( Action func ) where T : Exception
        {
            Exception exceptionOther = null;
            var exceptionThrown = false;
            try
            {
                func.Invoke();
            }
            catch ( T )
            {
                exceptionThrown = true;
            }
            catch (Exception e) {
                exceptionOther = e;
            }

            if ( !exceptionThrown )
            {
                if (exceptionOther != null) {
                    throw new AssertFailedException(
                        String.Format("An exception of type {0} was expected, but not thrown. Instead, an exception of type {1} was thrown.", typeof(T), exceptionOther.GetType()),
                        exceptionOther
                        );
                }

                throw new AssertFailedException(
                    String.Format("An exception of type {0} was expected, but no exception was thrown.", typeof(T))
                    );
            }
        }
    }
}

Puisque vous mentionnez l'utilisation d'autres classes de test, une meilleure option que l' ExpectedExceptionattribut est d'utiliser Shoudly 's Should.Throw .

Should.Throw<DivideByZeroException>(() => { MyDivideMethod(1, 0); });

Disons que nous avons une exigence que le client doit avoir une adresse pour créer une commande . Sinon, la CreateOrderForCustomerméthode devrait aboutir à un ArgumentException. Ensuite, nous pourrions écrire:

[TestMethod]
public void NullUserIdInConstructor()
{
  var customer = new Customer(name := "Justin", address := null};

  Should.Throw<ArgumentException>(() => {
    var order = CreateOrderForCustomer(customer) });
}

C'est mieux que d'utiliser un ExpectedException attribut, car nous sommes précis sur ce qui devrait déclencher l'erreur. Cela rend les exigences de nos tests plus claires et facilite également le diagnostic lorsque le test échoue.

Notez qu'il existe également un Should.ThrowAsynctest de méthode asynchrone.

Comme alternative, vous pouvez essayer de tester les exceptions qui sont en fait lancées avec les 2 lignes suivantes de votre test.

var testDelegate = () => MyService.Method(params);
Assert.Throws<Exception>(testDelegate);

Dans les tests unitaires intégrés VS si vous voulez simplement vérifier que "toute exception" est levée, mais que vous ne connaissez pas le type, vous pouvez utiliser un catch all:

[TestMethod]
[ExpectedException(typeof(Exception), AllowDerivedTypes = true)]
public void ThrowExceptionTest()
{
    //...
}

Eh bien, je vais résumer à peu près ce que tout le monde ici a dit avant ... Quoi qu'il en soit, voici le code que j'ai construit en fonction des bonnes réponses :) Tout ce qu'il reste à faire est de copier et d'utiliser ...

/// <summary>
/// Checks to make sure that the input delegate throws a exception of type TException.
/// </summary>
/// <typeparam name="TException">The type of exception expected.</typeparam>
/// <param name="methodToExecute">The method to execute to generate the exception.</param>
public static void AssertRaises<TException>(Action methodToExecute) where TException : System.Exception
{
    try
    {
        methodToExecute();
    }
    catch (TException) {
        return;
    }  
    catch (System.Exception ex)
    {
        Assert.Fail("Expected exception of type " + typeof(TException) + " but type of " + ex.GetType() + " was thrown instead.");
    }
    Assert.Fail("Expected exception of type " + typeof(TException) + " but no exception was thrown.");  
}

Consultez nUnit Docs pour des exemples sur:

[ExpectedException( typeof( ArgumentException ) )]

Cela dépendra du cadre de test que vous utilisez?

Dans MbUnit, par exemple, vous pouvez spécifier l'exception attendue avec un attribut pour vous assurer d'obtenir l'exception que vous attendez vraiment.

[ExpectedException(typeof(ArgumentException))]

En cas d'utilisation de NUnit , essayez ceci:

Assert.That(() =>
        {
            Your_Method_To_Test();
        }, Throws.TypeOf<Your_Specific_Exception>().With.Message.EqualTo("Your_Specific_Message"));

Il existe une bibliothèque géniale appelée NFluent qui accélère et facilite la façon dont vous écrivez vos assertions .

Il est assez simple d'écrire une assertion pour lever une exception:

    [Test]
    public void given_when_then()
    {
        Check.ThatCode(() => MethodToTest())
            .Throws<Exception>()
            .WithMessage("Process has been failed");
    }

Même s'il s'agit d'une vieille question, je voudrais ajouter une nouvelle réflexion à la discussion. J'ai étendu le modèle Arrange, Act, Assert à prévoir, Arrange, Act, Assert. Vous pouvez créer un pointeur d'exception attendu, puis affirmer qu'il a été affecté à. Cela semble plus propre que de faire vos Asserts dans un bloc catch, laissant votre section Act principalement juste pour la seule ligne de code pour appeler la méthode en cours de test. Vous n'avez pas non plus à aller Assert.Fail();ou à returnpartir de plusieurs points dans le code. Toute autre exception levée entraînera l'échec du test, car il ne sera pas intercepté, et si une exception de votre type attendu est levée, mais ce n'était pas celle que vous attendiez, Asserting contre le message ou d'autres propriétés de l'exception permet de vous assurer que votre test ne passera pas par inadvertance.

[TestMethod]
public void Bar_InvalidDependency_ThrowsInvalidOperationException()
{
    // Expectations
    InvalidOperationException expectedException = null;
    string expectedExceptionMessage = "Bar did something invalid.";

    // Arrange
    IDependency dependency = DependencyMocks.Create();
    Foo foo = new Foo(dependency);

    // Act
    try
    {
        foo.Bar();
    }
    catch (InvalidOperationException ex)
    {
        expectedException = ex;
    }

    // Assert
    Assert.IsNotNull(expectedException);
    Assert.AreEqual(expectedExceptionMessage, expectedException.Message);
}