断言已引发处理的异常

Question

I am handling several exceptions and not re-throwing them once handled. How can I assert the exception was invoked in my unit test.

Answer 1

What I would do is create a custom Exception for your legacy code and place the exceptions thrown by your legacy stuff into it's inner exception. Then you can always swallow your custom exception to ignore them in your main app but then they'll still be thrown for your unit testing.

Example:

try
{
    //rubbish legacy code which will throw all kinds of exceptions
}
catch(Exception ex)
{
    throw new CustomException(message: "something bad happened", innerException: ex);
}

Then normally you can do the following:

try
{
    MethodWhichCallsRubbishLegacyStuffAndWillProbablyThrowException();
}
catch (CustomException c)
{
    //do nothing or better yet - logging!
}
catch (Exception ex)
{
    //handle potential exceptions caused elsewhere
}

Now in your unit test you can assert against the CustomException or indeed the specific InnerException which was thrown.

Answer 2

Based on your comment in your question:

I am sending an email to first line support if one of my messages fails due to a legacy application interface which could throw many different exceptions for which I am handling. It would be nice for my test to assert the exception was thrown and handled.

The cleanest way to handle this is to make sure that the code that is handling the exceptions and then passing them on as an email receives the emailer as an Interface on your constructor.

You can then mock the email handler, pass that to your code under test, and Assert that it was given the proper type of exception.

Something like this:

public interface IExceptionEmailer {
    void HandleGenericException( Exception e );
    void HandleYourExceptionTypeA ( ExceptionTypeA e );
    // ... continue with your specific exceptions
}


public class YourClassThatCatchesExceptions( ){ 

    private IExceptionEmailer emailer;

    public void TheMethodThatCatches ( ) {

        try {
            // actions
        } catch ( ExceptionTypeA e ) {
            this.emailer.HandleYourExceptionTypeA( e );
        } catch ( Exception e ) {
            this.emailer.HandleGenericException( e );
        }
    }

    public YourClassThatCatchesExceptions( IExceptionEmailer emailer ) {
        this.emailer = emailer;
    }
}

Then your test class (assuming Moq and Xunit) would be:

public class GivenAnExceptionEmailer ( ) {

    [Fact]
    public void WhenYourSpecificActionHappens ( ) {

        var emailer = new Mock<IExceptionEmailer>();
        // ARRANGE the rest of your system here
        var target = new YourClassThatCatchesExceptions( emailer.Object );


        // do whatever ACTions needed here to make it throw
        target.Whatever( );


        // then ASSERT that the emailer was given correct type
        // this will fail if the exception wasn't thrown or wasn't
        // properly caught and handled.
        emailer.Verify ( e => 
            e.HandleYourExceptionTypeA ( It.IsAny<ExceptionTypeA>( )),
            Times.Once( )
        );
    }    
}

I haven't tested that so you may find syntax issues, but, that isolates your system so that you can verify that the exact behavior you expect in YourClassThatCatchesExceptions fires (and your admins will thank you for not spamming them with a bunch of test emails!)

Answer 3

I have done something like this, not sure its good practice or not...

First:

[TestMethod]
public void MethodName_TestErrorMessage_When_SomeException()
{
  // Arrange
  const string ExpectedMessgae= "Error in Application ";
  this.MockedInterface.Setup(x=>x.MethodCall()).Throws<SomeException>();

  // Act
  var result=this.Controller.Action() as JsonResult;

  // Assert
  Assert.AreEqual(ExpectedMessage, result.Data.ToString());
}

This is just an example, but typically if you are not re-throwing exception and it has been handled in code, then we can verify that the message is correct or not. But this also implies at least you have not lost the stack trace in your code and returning it. I will appreciate if someone helps me improving this. One other way is ExcpectedException Attribute, exception should not be handled for that.

Answer 4

Why care if nobody outside your code's gonna see it? I wouldn't unit test such functionality which is not exposed to the callers.