Testing 64-bit Oracle using Visual Studio

Vagif Abilov — Wed, 11 May 2011 20:26:35 GMT

I have installed 64-bit Oracle 11g on my development machine to work on some samples using Entity Framework 4.1 (a.k.a. “code first”). If you ask me why I installed 64-bit version and not 32-bit, I will not answer. I don’t know. Perhaps because Oracle has always associated for me with something big and 64 bits are certainly greater than 32. Now I think it was a mistake, but on the other hand it made me explore something new.

An attempt to connect to the database failed with the following error message: “ ----> System.Exception : Unable to load D:\Oracle\Vagif\product\11.2.0\dbhome_1\bin\oci.dll. Please check that you use 32x version of Oracle client with 32x application.” I checked project platform target. “Any CPU”. I was using TestDriven.NET test runner.

I’ve changed build platform to “64x” and tests passed. I also ran tests built for “Any CPU” using 64-bit NUnit runner, and they passed too. What I wanted now is leave “Any CPU” option for all projects and be able to test them from within Visual Studio.

Resharper was the only once that worked like a charm, no matter what I did. It uses 64-bit task runner on 64-bit platforms, so it just works.

Although TestDriven.NET test runner failed initially, it was easy to re-configure it: just choose 64-bit option for the test runner in its settings page.

~~The only bad guy was built-in Visual Studio test runner: it runs only as 32-bit process, so without unsupported patching it as 64-bit process (described~~ ~~here) it can’t run tests in 64-bit mode.~~

UPDATE. I stand corrected. MsTest also supports 64-bit mode.

NUnitForVS: integrating NUnit tests into Visual Studio

Vagif Abilov — Sat, 06 Mar 2010 20:23:45 GMT

Roy Osherove listed advantages of NUnit over MsTest but also mentioned one MsTest’s strength that can be crucial for many developers: “the integration with other team system tools and reporting is just beyond compare and the reporting alone helps alot to find recurring breaking tests, code churn vs. new tests and others”. This reminded me about what I recently read in a book by Jeff McWherter and Ben Hall Testing ASP.NET Web Applications where they said that forthcoming release of Visual Studio 2010 will make it possible to configure VS test runner to execute tests that use syntax different from MsTest.

I am a faithful user of TestDriven.Net, but I know that ability to use built-in Visual Studio test runner is an important factor that may affect the choice of unit test framework. So it would be nice to separate these decisions: selection of a unit test framework and selection of a test runner. I asked in Microsoft’s VS 2010 forum it new version of Visual Studio is really that flexible when it comes to configuring it’s test runner. Unfortunately not. Microsoft’s Euan Garden answered: “this was something we wanted to do in the release but never made it into the product.” However, Euan gave a couple of hints: Gallio and NUnit integration CodePlex project.

I checked CodePlex and found NUnitForVS: NUnit integration for Visual Studio 2008. I downloaded an ran the installer and within 5 minutes was able to make Visual Studio development environment to treat NUnit tests as they were native MsTest. The only preparation (in addition to installing NUnitForVS) was to open test project file in a text editor and add the following entry to the first PropertyGroup:

This has to be done to every test project that uses NUnit, but otherwise Visual Studio won’t be able to classify the project as a test project (why should it? – the only type of test projects that it natively recognizes is MsTest). After this change Visual Studio accepts NUnit tests, and you will see all your tests in the Test View window:

So far so good. Next checkpoint is to run and debug some of these tests. This also works well and test results are displayed in a respective window:

Note the very last test in this list, the one that is called “Add(2,3,5)”. This is a parameterized test implemented using TestCase attribute:

[TestCase(2, 3, 5)]
public void Add(int x, int y, int sum)
{
    Calculator calc = new Calculator();
    decimal result = calc.Add(x, y);
    Assert.AreEqual(sum, result, "Incorrect result");
}

So using NUnitForVS we can exploit features of NUnit 2.5 that don’t exist in MsTest, and still Visual Studio correctly treats them. This is good news.

When it comes to collecting code coverage, the situation is a little trickier. When I open code coverage window, I see not very encouraging message “Code Coverage is not enabled for this test run”:

Actually this is correct message: you have to explicitly enable code coverage instrumentation. But how? Apparently our solution sill lacks some piece, but luckily it’s easy to fix. All we need is to add a test configuration file with extension “testrunconfig”. Then we can activate its configuration and enable code coverage collection. One simple way to add such file is to add and then delete a test project to a solution (a “real” MsTest project). The MsTest project will be gone but will a trace in a form of test configuration file:

If you now enable code coverage instrumentation for assemblies in your solution and rerun the tests, you will see the coverate summary:

Pretty useless, isn’t it? The summary displays coverage only for the test assembly and not for the actual code under test. Why?

More googling, and the explanation came from Peter Stephen’s blog post: even though coverage instrumentation is enabled for all assemblies in our solution, one of assemblies was taken from a wrong place: the assembly under the test lies both in its own “bin” folder and in the “bin” folder of the test assembly, and it is there it has to be taken from. To resolve the problem you just need to add the assembly from a right place:

Note 2 copies of UnitTestDemo.dll. The unchecked one is the one that was added initially, the checked one was added manually. And everything works:

Of course, I only tried NUnitForVS on a very simple project. I plan to check it out with more complex code. But so far it looks quite promising opening Visual Studio test runner for NUnit - the most popular unit test framework.

When NUnit stops working on a build machine…

Vagif Abilov — Thu, 10 Dec 2009 12:13:58 GMT

… then it’s time to check the registry entries. Make sure you see something like this:

In case the build runs in the context of a dedicated user, not the one who logs on to a build machine and install applications, then it is likely that the build user does not have correct setup for NUnit assemblies. You can of course import missing registry entries into that user registry part, but the best is just to create them for everyone under LOCAL_MACHINE folder using path \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFolderEx.

Vagif Abilov's blog on .NET : unit testing, Visual Studio

Testing 64-bit Oracle using Visual Studio

NUnitForVS: integrating NUnit tests into Visual Studio

When NUnit stops working on a build machine…