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

Question

How do I use Assert (or other Test class) to verify that an exception has been thrown when using MSTest/Microsoft.VisualStudio.TestTools.UnitTesting?

Bartel

Doesn't ExpectedException attribute help? ref: msdn.microsoft.com/en-us/library/… – Oddity

Funny, I just finished looking for the answer to this, found it at https://mcmap.net/q/54464/-best-way-to-test-exceptions-with-assert-to-ensure-they-will-be-thrown. – Beaty

Also see: #741529 – Karleen

Possible duplicate of Best way to test exceptions with Assert to ensure they will be thrown – Greenhouse

Would be nice if we could change the accepted/most popular answer to the one that is correct in current usage. As of 2018, MSTestv2 supports Assert.ExpectedException<T>, which should always be considered preferable to ExpectedException; the attribute will succeed regardless of where the exception is thrown and cannot be localized to the code under test. – Brookbrooke

Answer 1

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

Angloamerican

ExpectedException attribute above works in NUnit as well (but [TestMethod] should be [Test]). – Development

@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) – Active

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. – Budgie

Avoid using ExpectedException in NUnit, as it will be dropped in NUnit 3.0. I prefer to use Assert.Throws<SpecificException>() – Randall

Just discovered I couldn't use [ExpectedException...] if the exception is private.As a workaround, I'm trapping exceptions in the test method and asserting that the expected exception name equals the actual exception name. – Kerekes

The annotation won't work if you catch an Exception. One may have the question why to even catch it. In the catch block I check the exception code in the Assertion and in the annotation I expect this exception to be thrown. Finally I used Assert.Fail method after the line where I expect the exception to be thrown. – Tobacconist

You can use Assert.ThrowsException<T> and Assert.ThrowsExceptionAsync<T> within MsTest. – Thanasi

It does not work in newer NUnit. Use Assert.Throws(typeof(Exception_Type), () =>yourMethod()); – Marriageable

See @GopalKrishnan's comment above. As of 2018, MSTestv2 supports Assert.ThrowsException<T> and should be considered preferable to ExpectedException attribute, which can succeed when the expected exception is thrown somewhere besides the code being tested. – Brookbrooke

Answer 2

Usually your testing framework will have an answer for this. (See the comments for this thread for examples, there's lots!) But if your framework isn't 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();
}

Courtneycourtrai

+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. – Decoteau

I like this because you don't have to specify the exact error message like with the attribute approach – Reste

You are not required to specify the error message. This is sufficient: [ExpectedException(typeof(ArgumentException))] – Dieball

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. – Bicollateral

Be careful with that because Assert.Fail() raise an exception, if you catch it, the test pass! – Various

@Various is it not a case that all asserts throw an exception? Is that not how they work? – Amylase

@Amylase 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) – Various

This technique is good in that it's more flexible than the ExpectedException attribute, but I do not recommend using this technique since it's too easy to make a mistake by catching the assertion exception. Use a well-designed assert method. See other answers. – Budgie

The most important reason to use this technique rather than the [ExpectedException] attribute is it is often important to verify the state of the object under test after it throws an exception -- i.e. can it still be used or did detecting the error leave it in a broken condition. [ExpectedExcepton] steals the control from your test. Overall I consider this a fairly large deficiency in the .NET Unit test support. – Pushkin

As of 2018, MSTestv2 supports Assert.ThrowsException<T> and should be considered preferable to ExpectedException attribute, which can succeed when the expected exception is thrown somewhere besides the code being tested. – Brookbrooke

Answer 3

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.

Commingle

Get rid of the bool flag and put the throw on the line directly after the invoke for a more compact implementation. – Skippet

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. – Hazem

@gt - see other comments in this thread. If T is Exception, the check to ensure the exception was thrown won't work. – Goldsberry

@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! – Warrick

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/… – Covenant

Answer 4

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

Jameejamel

Not wrong, but the question specifically is about MSTest/Microsoft.VisualStudio.TestTools.UnitTesting -- not NUnit – Budgie

Answer 5

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.

Fulford

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

Answer 6

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

Heptavalent

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. – Budgie

Can also use Assert.IsInstanceOfType(ex, typeof(SpecificExceptionType); – Marriage

Answer 7

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

Link

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/

Robynroc

Note that NUnit 2.5 also supports Assert.Throws style syntax now too - nunit.com/index.php?p=releaseNotes&r=2.5 – Spinster

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. – Tumbler

@Ant: MS copied NUnit...so the real question is, why did NUnit think it was a good idea? – Robynroc

Answer 8

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

First, I don´t like the ExpectedExceptionAttribute because it does take into consideration which method call that caused the Exception.

I do this with a helper method 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 ;)

Bonina

Answer 9

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

Cere

Answer 10

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

Security

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! – Genus

Answer 11

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

Stamp

Answer 12

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()
{
    //...
}

Hardship

Answer 13

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

Bartholomew

Answer 14

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

UPDATE

My approach is no longer valuable with mstest V2 which seems to have come out in 2018 or something. Use Assert.ThrowsException.

Unless you are stuck using an old version of mstest. Then, my approach still applies.

Budgie

Answer 15

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

Mendelevium

Answer 16

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

Windward

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. – Encrust

@Martin I'd remove the code involving exceptionOther and simply rethrow from the second catch clause – Borlase

Answer 17

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.

Entomophagous

Answer 18

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

Minorca

Answer 19

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

Selina

Answer 20

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

Sheepwalk

Answer 21

In case of using NUnit, try this:

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

Slur

Answer 22

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

Diploma

Answer 23

Check out nUnit Docs for examples about:

[ExpectedException( typeof( ArgumentException ) )]

Radke

Answer 24

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

Sandglass

Answer 25

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

Fame