RE: Use of ExpectedExceptionAttribute class in unit tests

Sounds like a useful idea – although only in places where COM interop is used. That’s a lot of places, but not everywhere, which makes it seem like a great thing to implement as an extension. If you send me your code, I’ll see if it can be fit into that model. I think it may be the example I’m looking for to drive a decorator pattern on TestCases that have already been built.

 

Charlie

 

---

From: nunit-developer-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:nunit-developer-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Boris Partensky
Sent: Wednesday, December 14, 2005 8:44 AM
To: nunit-developer@xxxxxxxxxxxxxxxxxxxxx
Subject: [nunit-developer] Use of ExpectedExceptionAttribute class in unit tests

 

Hello.

I work for a small billing software company, which has adopted NUNIT a couple of years back, and now every developer here writes NUINT tests during development cycle – this is a great product. Our software base is a combination of managed C#/C++ code and unmanaged COM code, which we still via COM Interop.

 Recently I encountered a small issue, which prompted me to change UNIT framework a little bit, and I wanted to know if you think it would be useful to integrate this change into the official version of framework.

            The issue comes up when I write negative tests and want to use ExpectedException attribute. Sometimes it is not enough to know the type of the exception when the test runs, but rather compare the instances of exception. A classic example of this would be testing on COM interop code, where every exception thrown is an instance of COMException class. So I always had to write additional code to examine the HRESULT on the exception, something like this:

 

[ExpectedException(typeof(System.Runtime.InteropServices.COMException))]

public void MyNegativeUseCase()

{

try

            {

                        ...                                

            }

            catch(COMException e)

            {

                       long  MY_EXPECTED_HRESULT = 0xEEBF004EL;

                          Assertion.AssertEquals(_EXPECTED_HRESULT, (long)e.ErrorCode);

                        throw;

           

            }

}

 

 

Recently I introduced another class called ExpectedComException, and things became much easier:

 

[ExpectedComException(0xEEBF004EL)]

public void TestAddInvalidConstraintToPO()

{

Utils.TestComException(0xEEBF004EL();

}

 

Basically, if a COMException with the error code different from the one that I expect, test suite throws an error indicating this. Although COMException is the only case where I needed this, I am pretty sure that it could be useful to create exception instance level attributes even for managed exceptions. Sometimes you may want to examine more than the type of exception to validate that your test succeeded.

 

If you think that this change may be useful, I will make things nice and neat and send the mods along with test cases.

Please let me know.

 

 

Thank you very much.

Boris Partensky