views:

47

answers:

2

I've got a method that does some IO that generally looks like this:

public bool Foo()
{
    try
    {
        // bar

        return true;
    }
    catch (FileNotFoundException)
    {
        // recover and complete
    }
    catch (OtherRecoverableException)
    {
        // recover and complete
    }
    catch (NonRecoverableException ex)
    {
        ExceptionPolicy.HandleException(ex, "LogException");
        return false;
    }
}

The method isn't mission critical to be completed, there are external recovery steps - and it's relatively common for NonRecoverableException to be thrown - it's in the spec for it to return false, report 'cannot be completed at this time' and processing moves along. A NonRecoverableException does not put the program in an invalid state.

When I'm unit testing, and one of these exceptions is thrown, I get the error that

Activation error occured while trying to get instance of type ExceptionPolicyImpl

And I'd like to suppress that in favor of getting the actual/original exception information instead of EntLib not being able to log (and, indeed to force the NonRecoverableException and have an [ExpectedException(typeof(NonRecoverableException))] unit test to ensure that this method complies with the spec.

How might I go about that?

edit Using preprocessor directives is not ideal as I hate seeing test-specific code in the codebase.

+1  A: 

Hmm, you could refactor the code to place everything in the try block in a separate method and configure you tests to call that instead of the existing method?

Doobi
I considered that, and it's a good idea, but it's a library function that I'm making and I'd like to keep the interface as clean as possible.
SnOrfus
Make it private or internal?
Doobi
+3  A: 

Testability of your code using the Entlib static facades is difficult. Without changing your code a little, your only answer is to add an app.config file to your test assembly and set up the Entlib exception block with an innocuous policy that does nothing.

However, in Entlib 4 (and 5, which I see you're using) there's another way. We added an instance entry point to all the blocks specifically to improve the testability story. For the exception block, that instance is the ExceptionManager. Using it is pretty simple. Get an exception manager instance into your type, and then call it instead of ExceptionPolicy. Something like this:

public class Whatever {
    private ExceptionManager exm;

    public Whatever(ExceptionManager exm) { this.exm = exm; }

    public bool Foo() {
        try {
            ... do whatever ...
        }
        catch(NonRecoverableException ex) {
            exm.HandleException(ex, "LogException");
            return false;
        }
    }
}

Now that you've got that in there, you can mock out the ExceptionManager (it's an abstract base class) to essentially no-op it during test, either manually or using a mock object framework.

If you don't want to force your users to use a DI container, you can add a default constructor that gets the current exception manager:

public class Whatever {
    private ExceptionManager exm;

    public Whatever() : this(EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>()) { }        
    public Whatever(ExceptionManager exm) { this.exm = exm; }
}

End users use the default constructor, your tests use the one that takes in an explicit ExceptionManager, and you have your hook to mock out anything Entlib uses.

All the blocks now have these "Manager" classes (where they make sense, anyway).

Chris Tavares
Well then; fantastic. Thank you very much. I'm going to mark this as accepted but in a day or so in the hopes that you'll get more upvotes for such a good answer.
SnOrfus