3

I have an application for smoke testing several key services. I want these tests to be easily written and self discovering. To this end, I have created an attribute for each method in the style of [TestMethod] from MSTest. I have also created a object that will find all these methods and execute them within a try-catch. If the method throws an exception I report as a failure, otherwise as a success.

This is all very unit test familiar and that is the intention. So a test would look like...

[MyTestAttribute]
public void TestingTimesAhead()
{
  var d = DateTime.MaxValue.AddDays(1);
}

The magic happens in the test object, this has an Action property and a Run method...

    public Action TestAction { get; private set; } 

    public override ITestResult RunTest()
    {
        try
        {
            this.TestAction.Invoke();
            return new BaseTestResult() { Result = TestResultStatus.Success };
        }
        catch(Exception ex)
        {
            return new BaseTestResult() { Result = TestResultStatus.Failure, FailureException = ex};
        }
    }

When ran in isolation the above test, being wrapped as the Action, will cause an exception and the test fails. Perfect.

However, when I wrap the attributes and test running object up into a dll and reference from a new project, VS Debugger breaks for the exception. I am presented with an option in that dialog to toggle 'break when this exception type is user-unhandled'. Exception screen shot

I can suppress exceptions on a type by type basis, but that isn't going to work for reuse. Also, if I run the release build from the BIN output, the expected behaviour is there - it's just a really awkward development experience.

Is it possible to manage this exception setting from my code instead? Or if anyone can suggest a way around the problem, I'm open to ideas.

kidshaw
  • 3,423
  • 2
  • 16
  • 28
  • 3
    Some (possibly simplified) code of that magical component that handles exceptions would make question better. Also "VS throws the exception " is very confusing statement - while VS indeed has bugs but I find it usually problem of user's code than VS... Maybe you are talking about some VS dialogs shown for exceptions when thrown? – Alexei Levenkov Apr 26 '15 at 06:22
  • Apologies, it is a standard debug exception dialog as you suggest. The code is neither magical or interesting :). It simply builds an action around the method and invokes in a try catch. I felt that adding it might detract from the problem. If it helps I will add it shortly. – kidshaw Apr 26 '15 at 06:33
  • I don't think you can disable dialog shown on "thrown" based on the fact that there is handler in external library... Side note: I assume your code is regular synchronous code or your `async` method properly wrapped with your exception handler code as you've said it worked fine while it was in the same project... – Alexei Levenkov Apr 26 '15 at 06:38
  • @AlexeiLevenkov - I have added some more details and a screen grab as that probably better isolates the issue. Thanks so far. – kidshaw Apr 26 '15 at 07:50
  • I don't know. You can try my favorite Tools->Options->Debug->My Code only (uncheck) as it changes what VS considers "user's code" (it has much broader impact, so try and see... You can also ensure PDBs are next to your library so VS will treat it as "user code" (http://stackoverflow.com/questions/9616715/what-does-visual-studio-consider-user-code) – Alexei Levenkov Apr 27 '15 at 00:40

0 Answers0