How to Assert Exceptions in MSTest (C#)

By the end of this page, you will understand how to test exceptions in MSTest using modern and older approaches. You will learn when to use Assert.ThrowsException<T>(), how it works, why it is usually preferred over attribute-based exception testing, and how to write clear, reliable exception tests in C#.

In unit testing, verifying exceptions is how you confirm that code fails correctly.

Sometimes a method is supposed to throw an exception when it receives invalid input, missing data, or an impossible state. A good test should check not only successful behavior, but also failure behavior.

In MSTest, the most common way to verify this is:

Assert.ThrowsException<ArgumentException>(() => SomeMethod());

This means:

• Run the code inside the lambda
• Expect an exception of type ArgumentException
• Fail the test if no exception is thrown
• Fail the test if a different exception type is thrown

This matters because exception tests help you:

• validate input rules
• protect against silent failures
• document intended behavior
• catch regressions when code changes

For example, if a method should reject a negative price, your test should prove that it throws an exception instead of returning bad data.

In modern MSTest, Assert.ThrowsException<T>() is usually the clearest and most precise choice. Older code may also use the [ExpectedException] attribute, but that approach is less flexible and usually less explicit.

Think of an exception test like a fire alarm drill.

You are not hoping the alarm goes off randomly. You deliberately trigger a known condition and verify that the correct alarm responds.

• Your code under test = the building system
• Invalid input or bad state = the smoke trigger
• Expected exception = the correct alarm
• The test = the inspector checking that the right thing happened

If no alarm goes off, something is wrong. If the wrong alarm goes off, something is also wrong.

That is exactly what exception assertions do in a unit test.

The most common MSTest syntax is:

Assert.ThrowsException<ExceptionType>(() =>
{
    // code that should throw
});

Basic example

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

[TestClass]
public class CalculatorTests
{
    [TestMethod]
    public void Divide_ByZero_ThrowsDivideByZeroException()
    {
        var calculator = new Calculator();

        Assert.ThrowsException<DivideByZeroException>(() =>
        {
            calculator.Divide(10, 0);
        });
    }
}

public class Calculator
{
    public int Divide(int a, int b)
    {
        if (b == 0)
        {
            throw new DivideByZeroException();
        }

        return a / b;
    }
}

Why this works

• Assert.ThrowsException<DivideByZeroException>() expects that exact exception type

Consider this example:

Assert.ThrowsException<ArgumentNullException>(() =>
{
    SaveFile(null);
});

And the method:

public void SaveFile(string path)
{
    if (path == null)
    {
        throw new ArgumentNullException(nameof(path));
    }

    // save logic
}

Here is what happens step by step:

1. The test starts running.
2. Assert.ThrowsException<ArgumentNullException> prepares to execute the lambda.
3. The lambda calls SaveFile(null).
4. Inside SaveFile, the condition path == null is true.
5. The method throws ArgumentNullException.
6. MSTest catches that exception.
7. MSTest checks whether the caught exception is exactly the expected type.
8. Because it matches, the assertion passes.
9. The test succeeds.

If SaveFile(null) did not throw anything, the test would fail.

If it threw instead of , the test would also fail.

Exception assertions are common in real software because many methods must reject invalid states.

Common scenarios

• Input validation
  • A registration method throws ArgumentException for invalid email input
• Null checks
  • A service throws ArgumentNullException when a required dependency or parameter is missing
• Business rules
  • An order service throws InvalidOperationException if checkout is attempted with an empty cart
• File and I/O handling
  • A file loader throws FileNotFoundException for missing files
• Parsing and conversion
  • A parser throws FormatException when input is not in the correct format
• Security and authorization
  • A method throws UnauthorizedAccessException when a user lacks permission

Example from an API-related service

public void SetPageSize(int pageSize)
{
     (pageSize <= )
    {
          ArgumentOutOfRangeException((pageSize));
    }
}

In real projects, developers usually use exception assertions together with a few common patterns.

Guard clauses

Guard clauses fail early when input is invalid.

public void SendEmail(string address)
{
    if (string.IsNullOrWhiteSpace(address))
        throw new ArgumentException("Email address is required.", nameof(address));

    // continue
}

Test:

Assert.ThrowsException<ArgumentException>(() => service.SendEmail(""));

Early validation

Many services validate arguments at the start of the method.

public void UpdatePrice(decimal price)
{
    if (price < 0)
        throw new ArgumentOutOfRangeException(nameof(price));
}

Verifying exception details

Real code often checks more than just the exception type.

1. Putting too much code inside the exception assertion

If you wrap too much code, the test may pass for the wrong reason.

Less clear

Assert.ThrowsException<ArgumentException>(() =>
{
    var service = new UserService();
    service.Initialize();
    service.CreateUser("");
});

If Initialize() throws, the test may still pass incorrectly depending on the expected type.

Better

var service = new UserService();
service.Initialize();

Assert.ThrowsException<ArgumentException>(() =>
{
    service.CreateUser("");
});

2. Using the wrong exception type

Assert.ThrowsException<Exception>(() => service.CreateUser(""));

This is usually too broad. Prefer the most specific type.

Better

Assert.ThrowsException<ArgumentException>(() => service.CreateUser(""));

3. Using [ExpectedException] for complex tests

Older MSTest code often uses:

[]
[]

{
     service =  UserService();
    service.CreateUser();
}

Common ways to test exceptions in MSTest

// Preferred MSTest pattern
Assert.ThrowsException<ArgumentException>(() => SomeMethod());

// Capture exception for more checks
var ex = Assert.ThrowsException<ArgumentNullException>(() => SomeMethod(null));
Assert.AreEqual("paramName", ex.ParamName);

Quick rules

• Use Assert.ThrowsException<T>() for most exception tests
• Keep only the failing call inside the lambda when possible
• Prefer specific exception types over Exception
• Capture the returned exception if you need to inspect it
• Use [ExpectedException] mainly when maintaining older tests

Older MSTest pattern

[ExpectedException(typeof(ArgumentException))]
[TestMethod]
public void TestMethod()
{
    SomeMethod();
}

Good exception types to know

• ArgumentException
• ArgumentNullException
• ArgumentOutOfRangeException
• InvalidOperationException

How do I assert that an exception was thrown in MSTest?

Use Assert.ThrowsException<T>() and place the code that should fail inside the lambda.

Assert.ThrowsException<ArgumentException>(() => DoWork());

Is Assert.ThrowsException<T>() better than [ExpectedException]?

Usually yes. It is more precise, easier to read, and lets you inspect the exception object.

Can I check the exception message in MSTest?

Yes. Store the returned exception and assert its properties.

var ex = Assert.ThrowsException<ArgumentException>(() => DoWork());
Assert.AreEqual("Invalid input.", ex.Message);

What happens if no exception is thrown?

The test fails because MSTest expected an exception and did not receive one.

What happens if the wrong exception type is thrown?

The test fails. Assert.ThrowsException<T>() expects the specific exception type you provide.

Should I test exact exception messages?

Only when necessary. Messages may change. Stable properties like ParamName are often better for argument-related exceptions.

Can I still use try/catch in MSTest?

Yes, but usually only when you need more control than provides.

• Unit testing — Exception assertions are a core part of testing behavior.
• Assertions — Exception checks are one type of assertion used in tests.
• Lambda expressions — MSTest uses lambdas to wrap code that should throw.
• Guard clauses — These are a common reason methods throw exceptions early.
• Argument validation — Many exception tests verify invalid input handling.
• Custom exceptions — Real applications sometimes throw domain-specific exceptions.
• Arrange Act Assert — Exception tests still follow this common test structure.