But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Speaking at Developer Day South West

I have just heard I will be speaking at Developer Day South West on June the 5th. My subject is Using the new Developer and Test features of VS 2010 to track down and fix bugs, this is basically the same session as I have at our TechDays fringe event yesterday.

Hope to see you there

DDDSouthWest2BadgeSmall[1]

Error running Ivonna tests with ASP.NET 4

When I tried to run a working Ivonna test, previously targeted at .NET 3.5, against .NET 4 I found my test failing with the error

------ Test started: Assembly: Webpart.Tests.dll ------
<html><body>Bad Request</body></html>
Setup information
Physical Web path: C:\Projects\Test\TypeMockSample\TestWebSite
Actual path: C:\Users\fez\AppData\Local\Temp\Temporary ASP.NET Files\root\156567f2

Turns out that the fix to simple, you have to use an absolute path i.e. the / in front of the BasicTest.aspx is vital

 

[TestMethod, Isolated]
        public void LoadWebPage_HelloWorldWebPart_NoError()
        {
            TestSession session = new TestSession(); //Start each test with this
            WebRequest request = new WebRequest("/BasicTest.aspx"); //Create a WebRequest object
            WebResponse response = session.ProcessRequest(request); //Process the request
            System.Web.UI.Page page = response.Page;
            //Check the page loaded
            Assert.IsNotNull(page);
        }

So this is a temporary work around for now, for me it is not an issue having to use a absolute path. I understand from the writer of Ivonna that this issue will be further investigated now that .NET 4.0 has RTM’d

Running Fitnesse.NET tests using MSTest - Revisited

In 2008 I wrote a post Running Fitnesse.NET tests using MSTest.  Recently I had need to us this technique on a VS2010 project, and as is so often the issue the code that worked then does not seem to work now. All I can assume is that the Fitnesse API had altered, but I thought I was using the same assemblies!

So I pulled down the code from http://sourceforge.net/projects/fitnessedotnet/ and had a poke about. Basically I seemed to be using the command line switches wrong. The listing below shows what I found is the working usage:

[TestMethod]
    public void WorkFlowSwitchOnName_DataViaFitnesse_Success()
    {
        fit.Runner.FolderRunner runner = new fit.Runner.FolderRunner(new fit.Runner.ConsoleReporter());
        var errorCount = runner.Run(new string[] {
                "-i",@"WF Workflow", // the directory that holds the HTM test files
                "-a",@"TestProject.dll",  //we have the fit fascard in this assembly
                "-o",@"results"}); // the directory the results are dumped into as HTML
        // fit can fail silently giving no failures as no test are run, so check for exceptions
        Assert.AreEqual(false, Regex.IsMatch(runner.Results, "^0.+?0.+?0.+?0.+?$"), "No tests appear to have been run");
        // look for expected errors
        Assert.AreEqual(0, errorCount, runner.Results);
        
    }

The –i option is the one that was wrong. I had been specifying a single HTM file. What I should have done was specify a directory that contains one or more HTM files. I handled this as a sub directory in my project with its contents set to copy to the output directory.

Once I made these edits I had my tests running again as expect.

Mixed mode assembly is built against version 'v2.0.50727' error using .NET 4 Development Web Server

If your application has a dependency on an assembly built in .NET 2 you will see the error below if you try to run your application when it has been built in.NET 4.

Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

This can be important in VS2010 testing, as test projects must be built as .NET 4, there is no option to build with an older runtime. I suffered this problem when trying to do some development where I hosted a webpart that make calls into SharePoint (that was faked out with Typemock Isolator) inside a ASP.NET 4.0 test harness

The answer to this problem is well documented, you need to add the useLegacyV2RuntimeActivationPolicy attribute to a .CONFIG file, but which one? It is not the web.config file you might suspect, but the C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0\WebDev.WebServer40.exe.config file. The revised config file should read as follows (new bits in red)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
            <supportedRuntime version="v4.0" />   
  </startup>

  <runtime>
    <generatePublisherEvidence enabled="false" />
  </runtime>
</configuration>

Note: Don’t add the following <supportedRuntime version="v2.0.50727" />  this cause the web server to crash on start-up.

Post QCon thoughts

Interesting time at QCon yesterday,  shame I was only there one day, I do like the events that are not limited to a single vendor or technology. The multi presenter session I was involved in on Microsoft interoperability seemed to go well, there is talk of repeating at other events or podcasting. It is a nice format if you can get the sub-sessions linking nicely, like themed grok talks. 

Due to chatting to people (but that why you go really isn't it?), I only managed to get to one other session, but I was the one I wanted to see, Roy Osherove’s on using CThru to enable testing of monolithic frameworks such as Silverlight. It got a few things clearer in my mind over using CThu, a tool I have tried to use in the past but not had as much success as I hoped. So I think I will have another go at trying to build a SharePoint workflow testing framework, the problem has rested on the back burner too long. I think I just need to persist longer in digging to the eventing model to see why my workflows under test do not start. Roy’s comment that there is no short cut for this type of problem to avoid an archaeological excavation into the framework under test, I think is the key here.

Do you use a Symbol Server?

I find one of the most often overlooked new features of 2010 is the Symbol Server. This is a file share where the .PDB symbol files are stored for any given build (generated by a build server, see Jim Lamb’s post on the setup). If you look on the symbol server share you will see directories for each built assembly with a GUID named subdirectory containing the PDB files for each unique build.

So what is this Symbol Server used for? Well you can use the Symbol Server to enable debug features such as Intellitrace, vital if you are using Lab Manager. In effect this means that when viewing an Intellitrace log Visual Studio is able to go to the Symbol Server to get the correct .PDB file for the assemblies being run, even if the source is not available, thus allowing you to step through the code. It can also be used for remote debugging of ASP.NET servers.

A bonus is that you can debug release code, as long as you produced .PDB symbols and placed them on the Symbol Server when you built the release (by altering the advanced build properties shown below).

image

Key to remember here is that the client PC that generates the Intellitrace file does not need access to the PDB files, only the PC handling the debugging process needs to be able to access the symbols. Perfect for release codes scenarios.

This ability to debug into code that you don’t have the source for extends to debugging into Microsoft .NET framework code. Microsoft have made public a Symbol Server for just this purpose. To use it you have to enable it using the Tool > Option > Debugging > Symbols dialog.

image

All this should make debugging that hard to track problem just that bit easier.

MTLM becomes MTM

You may have noticed that Microsoft have had another burst of renaming. The tester’s tool in VS2010 started with the codename of Camaro during the CTP phase, this became Microsoft Test & Lab Manager (MTLM) in the Beta 1 and 2 and now in the RC it is call Microsoft Test Manager (MTM).

Other than me constantly referring to things by the wrong name, the main effect of this is to make searching on the Internet a bit awkward, you have to try all three names to get good coverage. In my small corner of the Internet, I will try to help by updating my existing MTLM tag to MTM and update the description appropriately.

Is Pex and Moles the answer to Sharepoint testing?

I have got round to watching Peli de Halleux’s presentation on testing SharePoint with moles from the SharePoint Connections 2010 event in Amsterdam, very interesting. This brings a whole new set of tools to the testing of Sharepoint. I think it is best to view the subject of this presentation in two parts Pex and Moles, even though they are from the same stable; Moles being produced to enable Pex. But rather than me explaining how it all works just watch the video.

So to my thoughts, the easier bit to consider is Pex. If you can express your unit tests in a parameterised manner then this is a great tool for you. The example that Peli gives of an event handler that parses a string is a good one. We all have loads of places where this type of testing is needed, especially in Sharepoint. The problem here, as he points out, is that you need to use some form of mocking framework to allow the easy execution of these tests for both developers and automated build servers. I would usually use Typemock Isolator to provide this mocking, the problem is that Pex and Isolator at this time can’t run together. The Pex Explorer does not start the Typemock mocking interceptor, and thus far I can’t find a way to get round the problem.

So enters Moles, this is Microsoft Research’s subbing framework that ‘detour any .NET method to user-defined delegates, e.g., replace any call to the SharePoint Object Model by a user-defined delegate’. Now I find the Moles syntax is a bit strange. I suspect it is down to my past experience, but I still find the Typemock Isolator AAA syntax easier to read than Moles’. However, there are some nice wrapper classes provided to make it easier to use the Moles framework with Sharepoint.

So where does this leave us? At this time if you want to use Pex (and I certainly would like to) you have to use Moles (if you need stubbing). But you also have to remember that Pex & Moles are research projects. They are available for commercial evaluation, but at this time there seems to be no plans to productise it or roll it into Visual Studio, this means on effect no support. I don’t see either of these points as being a major barrier, as long as you make the choice to accept them knowingly.

However for ultimate flexibility it would be really nice to see Typemock Isolator being interoperable Pex, thus allowing me to use the new techniques of Pex against legacy tests already written using Isolator.

Errors Faking Sharepoint with Typemock due to assembly versions

I was doing some work today where I needed to fake out a SPWeb object. No problem you think, I am using Typemock Isolator so I just use the line

var fakeWeb = Isolate.Fake.Instance<SPWeb>();

But I got the error

Microsoft.SharePoint.SPWeb.SPWebConstructor(SPSite site, String url, Boolean bExactWebUrl, SPRequest request)
Microsoft.SharePoint.SPWeb..ctor(SPSite, site, String url)
eo.CreateFakeInstance[T](Members behavior, Constructor constructorFlag, Constructor baseConstructorFlag, Type baseType, Object[] ctorArgs)
eo.Instance[T](Members behavior)
(Points to the SPWeb web line as source of error)
TypeMock.MockManager.a(String A_0, String A_1, Object A_2, Object A_3, Boolean A_4, Object[] A_5)
TypeMock.InternalMockManager.getReturn(Object that, String typeName, String methodNAme, Object methodParameters, Boolean isInjected)
(Points to line 0 of my test class)

This seemed strange I was doing nothing clever, and something I have done many times before. Turns out the issue was the version of the Typemock assemblies I was referencing. I have referenced the 5.4 versions, once I repointed to the new 6.0 (or I suspect older 5.3 ones) all was OK.