Re: Assume

See inline:

Kelly Anderson wrote:
> On Fri, Feb 15, 2008 at 2:24 PM, Daniel M. Pomerantz
> <[email protected]> wrote:
>   
>> That makes perfect sense!  I forgot about NUnit handling the exception
>>  and was trying to come up with a way that you could implement it
>>  yourself...and actually you can.
>>     
>
> You could, but that would involve a lot of duplicated code, I think.
>
>   
>>  Truth be told though NUnice should be
>>  able to do that, and I like the concept.  I can't think of a particular
>>  situation where I would use it, but I'm sure it could come up!  For the
>>  record, as I'm sure you know, you can implement ExpectedException with
>>  your own Try/Catch, and that was the pattern I was using.
>>     
>
> Yeah, I had to take a lot of those out of my co-worker's test code.
> Really compacted the code a lot to use ExpectedException, with much
> less duplication.
>
>   
>>  One good
>>  thing about rolling your own ExpectedException, you can pinpoint/direct
>>  exactly which line of code throws the exception with your own
>>  try/catch.  ExpectedException cannot do that.
>>     
>
> Do you Assert the line of code threw the exception that you expected?
> That seems like the Test is tied too closely to the implementation for
> my taste.
>
>   

All I'm saying here is that if you have

[ExpectedException(typeof(InvalidCastException))]

And the test passes, all you know is that some line of code caused an 
invalid cast exception to be thrown.  I supposed you can have some 
degree of certainty that the line you wanted to throw the exception did, 
but I don't know of a way to enforce that.

Compare that too this:

public void foo()
{
    //Do some stuff here

    try
    {
        DoSomethingThatThrowsAnException();

        Assert.Fail("Exception not Thrown");
    }
    catch (InvalidCastException ex)
    {
        //Do Nothing...Swallow it
    }
}


In this case, you know exactly which line of code raised the exception.  
I'm not saying it's easier to maintain - To be 100% clear, I remove this 
second example of code and replace it with the first when I see it, as 
do you.  My point is that you have a bit more certainty that what 
happened is what you expected with this example, for better or for worse.

dmp

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/