bharry's WebLog

Brian,

I have been very excited about the test features in VS9.  Until very recently, however, they've been on my back burner.

With the recent posting of a MSDN video showing how to call native code from a VS test and as our VS9-based release begins to gel I've taken it back up.

I'm finding that the developer experience when trying to use VS9 unit tests within even moderately large native C++ solutions is extremely poor.  There is either an infinite loop or a superlinear algorithm in the implementation of the unit test project type that is looking at all the other loaded projects, even without dependencies.

There are other seriously trying issues as well.  In particular, there does not appear to be a way for the unit test code to discover, at build time or at run time, the pathname of the output folder for the build of which it is a part.  That seem to mean that a test method can only interact with output artifacts though explicit references.

There may be other scenarios in which this stuff competes but it isn't helping me right now.  And, as I said, I really wanted to use it.

Another issue that may be impacting the uptake of the testing features: as a Gold Partner we get a number of Team Dev licenses but, if I recall correctly, no Team Test or Architect licences.  Both of these feature sets would get more uptake in the ISV community if we could put them into our tool plans incrementally without having to commit to a large up-front expense.  If we are already entitled to use them a clarification would be useful.  If not, perhaps some thought could be given to a proportionate number of other SKUs under these plans -- to encourage best practices among the ISV community that keeps Windows on the sole source lists.

On another SKU-related issue, suppose a test managed by a user of Team Test edition fails.  We would like for the developer to be able to execute that test in the Team Dev environment and duplicate the failure.  We've not progressed far enough yet for me to be able to say this doesn't work but it looks likely that it won't, at least not without warping all tests into the unit test framework.  I'd like to see this scenario directly supported.

Thanks,

-swn

The US ISV Developer Evangelism Team on Team Foundation Server Works with Other Tools Eugene Zakehareyev...

Updating my previous rant, it looks like SP1 runs the infinite loop in a small number of minutes.  A unit test project is now usable even in our largest solution.  It's too slow to expect my younger colleages to be enthusiastic about using it but I'll keep nagging them and I'm now more confident than ever that you guys will get around to improving it.

I've really been enjoying Dr. Whittaker's blog.  The evil empire assimilates some very interesting people :-)

-swn

Spoke too soon, sorry.  I loaded the unit test ptoject, built and ran it, closed the solution, reopened it, built and ran it again.  So I posted my excited findings.  Then I unloaded and reloaded it.  Much joy, the screen started redrawing in only 30 seconds or so!

But, alas, it's been ten minutes now and VS isn't drawing anything when I try to switch to it.  So whatever the bug is, it's still there.  It just isn't happening every time.

One more update, since nobody seems to be following this I might as well use the virtual space.

I got in contact with one of the SDEs through a forum posting about a similar symptom.  He suggested something that appears to have cleared up this problem.  As a bonus, it looks like it might have cleared up the crash that happens occasionally when closing a large native solution.

The fix is to create a registry key (use the SysWoW64 version of regedt32.exe if you're on a 64-bit platform).  With that 64-bit caveat, see Michael Koltachev's suggestion in http://forums.microsoft.com/MSDN/ShowPost.aspx?siteid=1&PostID=3440877