I’m writing unit tests for a large solution which consists of a bunch of projects. Some small, calculation, utility type projects are in managed C++ and the rest are C#. When I run my tests under the GUI I get this error on one of the C++ DLLs:
Instrumentation error while processing file Util.dll:
Error VSP1014 : Unable to open file 'F:\src\Util\bin\Debug\Util.dll' for writing..
Now, under Team Suite 2005, this seems to be a well-known problem but that Knowledgebase article does not describe what is wrong here. For one thing, the error message is different even though the error number is the same. For two, this is my DLL so I have the PDB file for it. And for three, if I hop to the command line immediately after this error and invoke mstest.exe manually, the test runs fine. I don’t get the same error and code coverage is generated.
For now I think all code coverage will have to be done on the command line, as I’m completely stymied now. I can’t see any way around this.
Personal
.Net, Coding, VisualStudio
Is it just me or is this still rather half-baked, even now in 2008? Everywhere I turn I run across tiny little rough edges. Like this one: I am using Team Suite 2008 to generate code coverage data during a unit test run. I hit Run Tests and get 48 test run warnings, one per test/per referenced DLL, that say
“Code coverage instrumentation warning while processing file FooBar.dll: Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.”
So, yes. It simply cannot do code coverage on a 64-bit process. I’m running Vista x64, so naturally Visual Studio is starting up a 64 bit process, which the code coverage tool immediately fiddles with the CLR to drop it back to x86. This generates tons of sprurious warnings which (to top it all off) can be disabled on the comman line but not apparantly in the GUI. God knows what would happen if I were unit testing some subtle bug that only happened on the x64 platform.
On top of this, you still can’t Edit And Continue a running piece of code in the debugger properly if you are running x64. On my old Windows XP x64 workstation, it flat out didn’t work; now on Vista x64, it requires some messing around to breakpoint all running threads before it lets you get into the code.
I guess there must be some deep seated bits of the Windows API with some strongly held assumptions of 32 bittiness behind the scenes, and that what I am seeing are the rough edges of that hackery.
Personal
.Net, Coding
Gah!
Say I am writing a unit test for a class that converts metres to feet. This, naturally, involves floats. Ideally my code looks like
float expected=32.91; // in feet
Distance dist = new Distance (10,”m”);
Assert.AlmostEquals(dist.convertToUnit(”ft”),expected);
where the “AlmostEquals” method does something smart like compares the first decimal place or so. I think JUnit/NUnit/etc actually allow you to spec a precision.
Microsoft haven’t managed this, so I have to write stuff like
float expected=32.91; // in feet
Distance dist = new Distance (10,”m”);
float difference = Math.abs(expected - dist.convertToUnit(ft)); // java ism, not sure of the .net Abs method offhand
Assert.IsTrue(difference<0.01);
Unit tests need to be as crystal clear in their intent and as quick to write as possible. Every little tiny rough edge will catch your project thousands of times over. So a big “bah” to Microsoft for this one.
Personal
.Net, Agile, Coding, Rants, VisualStudio
Recent Comments