Instead of [DebuggerHidden] on the method try applying [SystemInternal] to the class. This attribute is defined in the Gallio.Common.Diagnostics namespace in v3.1. Jeff.
_____ From: [email protected] [mailto:[email protected]] On Behalf Of Kelly Brownsberger Sent: Saturday, August 29, 2009 2:34 PM To: [email protected] Subject: MbUnit Re: Extension Methods and StackFrames Thanks for the response Jeff - here's what I'm trying to do: using System.Diagnostics; using MbUnit.Framework; namespace MbUnitTesting { [TestFixture] public class SomeFixture { [Test] public void This_Is_A_Test() { string value = "foo"; value.AssertIsEqual("bar"); } } public static class ExtensionMethods { [DebuggerHidden] public static void AssertIsEqual<T>(this T actual, T expected) { Assert.AreEqual(actual, expected); } } } When This_Is_A_Test fails, and I double click it from the Error window in Visual Studio, I'm navigated to the Assert.AreEqual(...) statement within the AssertIsEqual Extension Method. I'd like to be taken to the "value.AssertIsEqual(...)" statement within This_Is_A_Test(). All the niceness of the Extension Method melts away when you add this navigation friction. Any way to avoid this? On Sat, Aug 29, 2009 at 3:15 PM, Jeff Brown <[email protected]> wrote: Kelly, You should still be able to double-click on the stack trace emitted by TDNet in the Visual Studio Output window. MbUnit v3 does respect [DebuggerHidden] on methods and filters them out. We use this extensively within Gallio to lighten stack traces. However there are a few special circumstances in which the filtering will not work. Could you give me an example of the full stack trace that is written to the Output window from one of your test failures? Jeff. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of kellyb Sent: Friday, August 28, 2009 9:59 PM To: MbUnit.User Subject: MbUnit Extension Methods and StackFrames We've built out numerous Extension Methods to our domain model that houses our assertion logic. This gives us some very nice reuse across our unit tests, but the problem we're now running into is when a test fails, the location of the failed test is obfusticated by this technique. We're using TestDriven.NET and we can no longer double- click the failed test in the Errors window of Visual Studio and be navigates to the failing test. Instead, you're navigated to the assertion extension method. The more logic we centralize, the harder it is navigate our test code. I thought I remember reading about an attribute I can decorate our assertion extension methods to make MbUnit ignore them? I've tried [DebuggerHidden] and [DebuggerNonUserCode], and neither do the trick. Any tips? thanks -kelly --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mbunituser?hl=en -~----------~----~----~----~------~----~------~--~---
