ChatGPT解决这个技术问题 Extra ChatGPT

How do I use Assert to verify that an exception has been thrown?

How do I use Assert (or other Test class) to verify that an exception has been thrown?

Which unit testing framework are you using?
Visual Studio Integrated
Doesn't ExpectedException attribute help? ref: msdn.microsoft.com/en-us/library/…
Funny, I just finished looking for the answer to this, found it at stackoverflow.com/questions/741029/testing-exceptions.

K
Kevin Pullin

For "Visual Studio Team Test" it appears you apply the ExpectedException attribute to the test's method.

Sample from the documentation here: A Unit Testing Walkthrough with 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");
}

ExpectedException attribute above works in NUnit as well (but [TestMethod] should be [Test]).
@dbkk: Doesnt work exactly the same in NUnit - the message is treated as a string that needs to matcvh the exception message (and IU think that makes more sense)
This attribute gets the job done and is a built-in feature for c# programmers, but I do not recommend using it since it is not flexible enough. Consider what happens if the exception type is thrown by your test setup code: test passes, but didn't actually do what you expected. Or what if you want to test the state of the exception object. I usually want to use StringAssert.Contains(e.Message...) rather than test the whole message. Use an assert method as described in other answers.
Avoid using ExpectedException in NUnit, as it will be dropped in NUnit 3.0. I prefer to use Assert.Throws()
You can use Assert.ThrowsException and Assert.ThrowsExceptionAsync within MsTest.
a
andrew

Usually your testing framework will have an answer for this. But if it's not flexible enough, you can always do this:

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

As @Jonas points out, this DOES NOT work for catching a base Exception:

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

If you absolutely must catch Exception, you need to rethrow the Assert.Fail(). But really, this is a sign you shouldn't be hand-writing this; check your test framework for options, or see if you can throw a more meaningful exception to test for.

catch (AssertionException) { throw; }

You should be able to adapt this approach to whatever you like -- including specifying what kinds of exceptions to catch. If you only expect certain types, finish the catch blocks off with:

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

+1, I use this way instead of the attribute when I need to make assertions beyond just the type of exception. For example, what if one needs to check that certain fields in the exception instance are set to certain values.
You are not required to specify the error message. This is sufficient: [ExpectedException(typeof(ArgumentException))]
I think this solution is the best. [ExpectedException(typeof(ArgumentException))] has it's uses, if the test is simple, but it is in my view a lazy solution and being to comfortable with can lead to pitfalls. This solution give you specific control to do a more correct test, plus you can to a test Writeline to your test run report, that the exception was indeed thrown as expected.
Be careful with that because Assert.Fail() raise an exception, if you catch it, the test pass!
@Vinnyq12 What I mean is that the first test in the example above will never fail. A test fail if an exception is thrown (and not "catch" by the ExpectedExceptionAttribute)
M
Mohsen Rajabi

My preferred method for implementing this is to write a method called Throws, and use it just like any other Assert method. Unfortunately, .NET doesn't allow you to write a static extension method, so you can't use this method as if it actually belongs to the build in Assert class; just make another called MyAssert or something similar. The class looks like this:

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

That means that your unit test looks like this:

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

Which looks and behaves much more like the rest of your unit test syntaxes.


Get rid of the bool flag and put the throw on the line directly after the invoke for a more compact implementation.
The only thing that makes this better is having the function return the caught exception so that you can continue asserting that things like the attributes on the exception is correct.
Thanks! This seems like the best approach to me because it's a short way to test multiple exceptions in one method. It's also much more readable.
@MickeyPerlstein Attributes break the AAA rules for testing. Specifically, if your Arrange happens to throw the exception before you even get to the Act, then your test passes... eek!
Microsoft has finally got round to updating MSTest - v2 supports Assert.ThrowsException<T> and Assert.ThrowsExceptionAsync<T> - see blogs.msdn.microsoft.com/visualstudioalm/2017/02/25/…
M
Martin

if you use NUNIT, you can do something like this:

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

It is also possible to store the thrown exception in order to validate it further:

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

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


J
Jon Limjap

If you're using MSTest, which originally didn't have an ExpectedException attribute, you could do this:

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

This does work, but I do not recommend this in general since the logic is overly complicated. Not saying it's convoluted, but consider if you write this block of code for multiple tests -- 10s, 100s of tests. This logic needs to be farmed out to a well-designed assert method. See other answers.
Can also use Assert.IsInstanceOfType(ex, typeof(SpecificExceptionType);
a
asidis

MSTest (v2) now has an Assert.ThrowsException function which can be used like this:

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

You can install it with nuget: Install-Package MSTest.TestFramework


In 2018 this is considered the best practice since it checks only the unit under test is throwing and not some other code.
L
Liam

Be wary of using ExpectedException, as it can lead to several pitfalls as demonstrated here:

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

And here:

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

If you need to test for exceptions, there are less frowned upon ways. You can use the try{act/fail}catch{assert} method, which can be useful for frameworks that don't have direct support for exception tests other than ExpectedException.

A better alternative is to use xUnit.NET, which is a very modern, forward looking, and extensible unit testing framework that has learned from all the others mistakes, and improved. One such improvement is Assert.Throws, which provides a much better syntax for asserting exceptions.

You can find xUnit.NET at github: http://xunit.github.io/


Note that NUnit 2.5 also supports Assert.Throws style syntax now too - nunit.com/index.php?p=releaseNotes&r=2.5
The way that the unit tests stop to let you know about the exception when using ExpectedException drives me crazy. Why did MS think it was a good idea to have a manual step in automated tests? Thanks for the links.
@Ant: MS copied NUnit...so the real question is, why did NUnit think it was a good idea?
G
Glenn

In a project i´m working on we have another solution doing this.

First I don´t like the ExpectedExceptionAttribute becuase it does take in consideration which method call that caused the Exception.

I do this with a helpermethod instead.

Test

[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, isn´t it;)


C
Cfrim

You can achieve this with a simple one-line.

If your operation foo.bar() is async:

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

If foo.bar() is not async

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

There are a lot of other answers, for me I was looking for a shorthand way to test for known fail conditions by Exception Type only, this makes for the easiest readable test cases. NOTE: the Exception Type does not match on inherited exceptions classes like a standard try-catch, so the above example will not trap an ArgumentException for instance. The old Try Catch and test the exception response is still preferred if you have advanced criteria to test, but for many of my cases, this helps a lot!
b
bytebender

It is an attribute on the test method... you don't use Assert. Looks like this:

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

B
Bradley Braithwaite

You can download a package from Nuget using: PM> Install-Package MSTestExtensions that adds Assert.Throws() syntax in the style of nUnit/xUnit to MsTest.

High level instructions: download the assembly and inherit from BaseTest and you can use the Assert.Throws() syntax.

The main method for the Throws implementation looks as follows:

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

Disclosure: I put together this package.

More Info: http://www.bradoncode.com/blog/2012/01/asserting-exceptions-in-mstest-with.html


Thanks for the example. Do you have an example of how to test a Assert.DoesNotThrow() or equivalent?
T
TTT

In VS built-in unit testing if you simply want to verify that "any exception" is thrown, but you don't know the type, you can use a catch all:

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

s
steve

I do not recommend using the ExpectedException attribute (since it's too constraining and error-prone) or to write a try/catch block in each test (since it's too complicated and error-prone). Use a well-designed assert method -- either provided by your test framework or write your own. Here's what I wrote and use.

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

Example uses:

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

NOTES

Returning the exception instead of supporting a validation callback is a reasonable idea except that doing so makes the calling syntax of this assert very different than other asserts I use.

Unlike others, I use 'propagates' instead of 'throws' since we can only test whether an exception propagates from a call. We can't test directly that an exception is thrown. But I suppose you could image throws to mean: thrown and not caught.

FINAL THOUGHT

Before switching to this sort of approach I considered using the ExpectedException attribute when a test only verified the exception type and using a try/catch block if more validation was required. But, not only would I have to think about which technique to use for each test, but changing the code from one technique to the other as needs changed was not trivial effort. Using one consistent approach saves mental effort.

So in summary, this approach sports: ease-of-use, flexibility and robustness (hard to do it wrong).


r
roeiba

Well i'll pretty much sum up what everyone else here said before...Anyways, here's the code i built according to the good answers :) All is left to do is copy and use...

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

M
Martin Connell

The helper provided by @Richiban above works great except it doesn't handle the situation where an exception is thrown, but not the type expected. The following addresses that:

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

Hmmm... I understand the idea, but I'm not sure I agree it's better. Just because we want to ensure a specific exception is raised doesn't mean all others should be wrapped up as an assertion failure. IMHO an unknown exception should just bubble up the stack as it would in any other assert operation.
@Martin I'd remove the code involving exceptionOther and simply rethrow from the second catch clause
o
ono2012

Since you mention using other test classes, a better option than the ExpectedException attribute is to use Shoudly's Should.Throw.

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

Let's say we have a requirement that the customer must have an address to create an order. If not, the CreateOrderForCustomer method should result in an ArgumentException. Then we could write:

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

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

This is better than using an ExpectedException attribute because we are being specific about what should throw the error. This makes requirements in our tests clearer and also makes diagnosis easier when the test fails.

Note there is also a Should.ThrowAsync for asynchronous method testing.


M
Matias

As an alternative you can try testing exceptions are in fact being thrown with the next 2 lines in your test.

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

B
Bashir Momen

I know this thread is old and has many good answers but maybe worth mentioning that local function can help in a very simple way.

//Arrange

//Act
void LocalFunction() => mr.ActualMethod(params);

//Assert
Assert.Throws<Exception>(LocalFunction);

A
Amir Chatrbahr

In case of using NUnit, try this:

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

m
mirind4

There is an awesome library called NFluent which speeds up and eases the way you write your assertions.

It is pretty straightforward to write an assertion for throwing an exception:

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

J
Jon Masters

Check out nUnit Docs for examples about:

[ExpectedException( typeof( ArgumentException ) )]

P
Peter Majeed

This is going to depend on what test framework are you using?

In MbUnit, for example, you can specify the expected exception with an attribute to ensure that you are getting the exception you really expect.

[ExpectedException(typeof(ArgumentException))]

A
Adam Venezia

Even though this is an old question, I would like to add a new thought to the discussion. I have extended the Arrange, Act, Assert pattern to be Expected, Arrange, Act, Assert. You can make an expected exception pointer, then assert it was assigned to. This feels cleaner than doing your Asserts in a catch block, leaving your Act section mostly just for the one line of code to call the method under test. You also don't have to Assert.Fail(); or return from multiple points in the code. Any other exception thrown will cause the test to fail, because it won't be caught, and if an exception of your expected type is thrown, but the it wasn't the one you were expecting, Asserting against the message or other properties of the exception help make sure your test won't pass inadvertently.

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

A
Arthur Zennig

This works for Visual Studio Team Test (a.k.a MSTest) While dealing with databases or http transaction. System should throw an exception somewhere, using Assert.ThrowExceptionAsync<>() will catch the your Throw event. (In these cases, Assert.ThrowException<>() does not catch the exception).

   [TestMethod]
   public void Invalid_Input_UserName_Should_Throw_Exception()
   {
       await Assert.ThrowExceptionAsync<ExpectedExceptionType>(()=> new LogonInfo(InvalidInputInUserNameFormat,"P@ssword"));
   }

B
Ben Osborne

FluentAssertions Examples

Adding an example using FluentAssertions for those using that library.

// act
Action result = () => {
    sut.DoSomething();
};

// assert
result.Should().Throw<Exception>();

Async Example

// act
Func<Task> result = async () => {
    await sut.DoSomethingAsync();
};

// assert
await result.Should().ThrowAsync<Exception>();