Visual Studio Object Test Bench

Yesterday I was in Mountain View at the Microsoft Campus presenting a session on debugging for MSDN Events and I asked the hundred or so developers there if they had heard of the Visual Studio Object Test Bench. I was surprised when not a single person raised their hand and so I thought I would write a blog post to show you just how useful this feature truly is.

Within Visual Studio 2005 and Visual Studio 2008 you'll find the Object Test Bench from the View, Other Windows, Object Test Bench menu.

Once you have the Object Test Bench open you'll be able to create instances of classes from the Class View and then call static or reference methods upon that type. Static and reference methods inherited from base types can also be called.

We'll use an open source exception management framework, CodePlex.Diagnostics, that I designed and developed to explore the Object Test Bench. Here you'll see that the Object Test Bench has been opened just below the Visual Studio text editor and we'll attempt to invoke the static method Publish from the ExceptionProvider class. We do this by right clicking on the class within the Visual Studio Class View.

Unfortunately we're unable to invoke this method just yet because the Publish method expects two parameters to be supplied, the exception to be published and the associated security identity.

We'll therefore create instances of these types within the Object Test Bench which we can then use to call the Publish method. Within the CodePlex.Diagnostics framework there is an UnhandledException class and so we'll create an instance of that exception type within the Object Test Bench.

The constructor of the UnhandledException class takes as an argument a string and so we'll simply provide a string for the exception message. You'll see that once the instance is created it is placed upon the Object Test Bench.

We'll now create an instance of the identity using the GetCurrent method of the .net framework WindowsIdentity class. Open the Project References of the CodePlex.Diagnostics project within the Class View and navigate to the WindowsIdentity class. Right click on the WindowsIdentity class and select Invoke Static Method.

Visual Studio will then display the Invoke Method dialog confirming the method you're about to call and displaying the Xml documentation comments from the code. This can be useful if you are not sure whether you have selected the correct method or not. Click OK and you'll then be presented with another dialog where you can name the variable within which you'll store the instance you have just created.

Once that instance of the object has been created and has been saved within the variable you have specified you'll see that object within the Object Test Bench.

With the exception and identity objects within the Object Test Bench we can now test the static Publish method from the ExceptionProvider class. We'll right click on the ExceptionProvider class within the Class View and select Invoke Static Method. Visual Studio will then display the Invoke Method dialog so that we can specify the parameters to the method.

If you drop down the list for the exception parameter you'll see that we can either invoke the method passing null for the exception or we can select the exception object already located within the Object Test Bench. We'll select the ex variable which contains the UnhandledException we created earlier.

When we select the identity instance however you may be surprised to see that it does not show within the drop down list. Within the Object Test Bench we have an instance of the WindowsIdentity class although this parameter is typed as the IIdentity interface. Although the WindowsIdentity class implements the IIdentity interface the Invoke Method dialog will not display that instance within the drop down list.

In fact typing the variable name within the Value column will still not allow you to invoke the method even though you would be able to pass an instance of the WindowsIdentity class to the method at runtime due to the fact that it implements the IIdentity interface.

I'm going to log this as a defect on Microsoft Connect and will provide a link to the Microsoft Connect feedback item in a comment to this post. Since this has been the behavior since Visual Studio 2005 we'll see what the Visual Studio team says about this but given the fact that the WindowsIdentity class, for example, implements the IIdentity interface I would expect it to appear in the drop down list and enable you to invoke the method accordingly.

The Object Test Bench, as you'll see is still very useful although I have shown you this limitation just so you're aware of it. In order to proceed I'll add a small amount of code to the ExceptionProvider class that will be compiled only in a debug build. The static method GetIdentity will then return us the WindowsIdentity as an IIdentity.

Using the newly defined static GetIdentity method we'll add the IIdentity instance to the Object Test Bench and we're now be able to call the static Publish method of the ExceptionProvider class.

Within the Invoke Method dialog we'll now be able to drop down the lists for the exception and identity objects and select those objects from the Object Test Bench.

Once the method has been executed your able to save the result to the Object Test Bench using the Method Call Result dialog.

You might be wondering what would have happened if you had placed breakpoints in your code when you were using the Object Test Bench. Well, if you invoke a method within the Object Test Bench and have breakpoints within that method you'll be able to use the debugger and step through the code just as you otherwise would. Here you'll see I placed a breakpoint within the Publish method and the breakpoint was hit after invoking the method through the Class View using the instances of the exception and identity within the Object Test Bench. Once the debugging session is completed you are then afforded the opportunity to save the result once again to the Object Test Bench.

I mentioned before that I'll submit a feedback item on Microsoft Connect for the inability to select the WindowsIdentity as an IIdentity. One other feedback item I'll suggest would be an ability to simply type new Exception() within the Invoke Method dialog which would possibly prevent you from having to create temporary objects within the Object Test Bench simply to call a given method. Both feedback items will be listed within the comments to this blog post and I encourage you to visit Microsoft Connect and vote on them as Microsoft does listen to users suggestions and defect reports and will respond to feedback provided there.

Using the Object Test Bench you are able to test or debug a class in isolation without having to spend time running your application and establishing the correct scenario. Sometimes getting the application established to test a method in this way can take minutes or even hours and this is where the Object Test Bench pays for itself very quickly.

Per informazioni più dettagliate sulle ottimizzazioni basate su compilatore, vedere il nostro Avviso sull'ottimizzazione.