locked
Unit testing and exceptions RRS feed

  • Question

  • Hello,

    I'm currently writing a test project for our inhouse framework. When I use a target and accessor everything works just fine. There is 1 thing that is going wrong: When I use a method from the Business class I'm testing e.g. accessor.Create(...) and this method in out business class throws an InvalidBusinessOperationException (custom exception) the testmethod exceptionhandling is catching the exception as a TargetInvocationException, in the innerexception there is the InvalidBusinessOperationException. Because I'm using the ExpectedException attribute where I say the type is InvalidBusinessOperationException the test fails.

    Is there a way to say that the exception should not get encapsulated inside the TargetInvocationEception or do I really need to go and check inside the catch block of which type the exception (and if there is an innerexception) is?
    Thursday, June 1, 2006 12:43 PM

Answers

  • Calls that go through reflection (which is how the accessing of non-public magic happens) always wrap exceptions this way.

    I have 'fixed' this in the next version of the product by unwrapping the exception, patching the stack log and throwing the inner exception.

    Until then, yes, you should be prepared to handle this case.

    Joe

     

    Thursday, June 1, 2006 10:58 PM

All replies

  • Hello! Under some circumstances (e.g. when you use reflection or remoting) .NET will give you TargetInvocationException with InnerException being the real exception. In VS 2005 RTM our ExpectedException attribute does not have a way (constructor) to verify inner exceptions but we can definitely consider this for next version. To verify InnerException the test has to do try-catch and Assert in the catch to verify the inner exception.

    Can you please provide more details about your test and what exact call throws TargetInvocationException, and may be we can help you with a workaround.

    Thank you,
    Michael Koltachev,
    VSTS

    Thursday, June 1, 2006 4:48 PM
  • Calls that go through reflection (which is how the accessing of non-public magic happens) always wrap exceptions this way.

    I have 'fixed' this in the next version of the product by unwrapping the exception, patching the stack log and throwing the inner exception.

    Until then, yes, you should be prepared to handle this case.

    Joe

     

    Thursday, June 1, 2006 10:58 PM
  •  Michael Koltachev wrote:
    Can you please provide more details about your test and what exact call throws TargetInvocationException, and may be we can help you with a workaround.

     

    Michael,

    I found a certain pattern during my testing. I can use the ExpectedException attribute when I call my business method directly from the target object, when I need the accessor object to access private methods I do a try catch and use the Assert.IsInstanceOfType method to certify if the innerexception is the expected exception.

    Example using try catch:

    <DeploymentItem("somefile")> _
    <DeploymentItem(
    "somefile")> _
    <TestMethod()> _
    Public Sub RetrieveFrameworkTest()

    Try
    Dim target As Framework = CodeAccessors.SylisBelgium_Framework_Business_FrameworkAccessor.CreatePrivate(CallTicketHelper.Create)

    Dim accessor As CodeAccessors.SylisBelgium_Framework_Business_FrameworkAccessor = New CodeAccessors.SylisBelgium_Framework_Business_FrameworkAccessor(target)

    Dim actual As DataSet
    actual = accessor.Retrieve(
    "ADMIN")

    Catch ex As Exception

    Assert.IsInstanceOfType(ex.InnerException, GetType(InvalidBusinessOperationException))

    End Try
    End Sub

    Friday, June 2, 2006 7:34 AM