Jonathan has just emailed me to let me know that the DeveloperDeveloperDeveloper website has been updated with the details of the next event on 22nd October. I strongly recommend going along - the last one was excellent.

Having used team test for unit testing since .NET beta 2 came out, I've finally got some time to set the build machine up to run the tests. It sounds like it should be quite straight forward, as there is a command line version of the test runner, mstest.exe. This has the command line parameters that one would expect: the .vsmdi file containing the test list, the localtestrun.testrunconfig file that contains (amongst other things) the locations of the test data and dependencies, and the path to the assembly being tested.

This is fine, and works well from the command line, when you know where these files are. On our build, we currently have around 30 solutions, each containing (as a minimum) a class library project and a test project, and there's no way I want to write the command lines out by hand, especially as we're still quite near the beginning of the project.

The double star in MSBuild is really useful to recursively find files in a directory tree, so I'm using this to find all the .vsmdi files under the source root:

<testmetadata include="C:\Build\Root\Source\**\*.vsmdi">

I can't see an MSBuild task for running tests yet, so I'm using the Exec task. The localtestrun.testrunconfig file is found in the same directory as the .vsmdi file by default, so there's one less search to do. The assembly however, is four directories lower in the solution, e.g. SolutionDir\Tests\TestProject\bin\Debug.

As the TestProject directory name is different for each of the solutions, I can't hard-code the path relative from the .vsmdi directory. I've not found a way to use a combination of **, $, % and @ in MSBuild to find the assembly under the path either.

In the .vsmdi file, it is possible to specify the assembly that the tests are run against, by (strangely enough) creating a new test list, and moving the existing tests into this list. There's bound to be a better way, but this is the first thing I found that works. Doing this adds the list of tests to the file, and the assembly is specified in the node in the XML. The location of the localtestrun.testrunconfig is also stored in the file, and the assembly location is also stored in the localtestrun.testrunconfig file.

The problem with this approach (for me) is that absolute paths are used. The source root directory on the build machine is different to those used by the developers. This means that the build script will work on the machine where the test project was setup, but not on the build machine. The only way I've found to fix this so far is to write a utility that rewrites the paths in both the .vsmdi and the localtestrun.testrunconfig files.

This utility is run prior to mstest in the build process, and uses the directory where the .vsmdi or localtestrun.testrunconfig is located as the solution root, and replaces the paths accordingly.

So, the build script:


<itemgroup>
<testmetadata include="C:\Build\Root\Source\**\*.vsmdi">
</itemgroup>
<target name="RunTests">
<exec command="'TestConfigAbsolutePath.exe" workingdirectory="Root\Source\Tools\TestConfigAbsolutePath">
<exec command="TestConfigAbsolutePath.exe %(TestMetaData.RootDir)%(TestMetaData.Directory)localtestrun.testrunconfig" workingdirectory="Root\Source\Tools\TestConfigAbsolutePath">
<exec command="'mstest.exe">
</target>


Each <exec> will be run one per .vsmdi file found using **. %(TestMetaData.FullPath) will give the full file name of the .vsmdi, and %(TestMetaData.RootDir)%(TestMetaData.Directory) will give the directory that contains it, which can be used as the path to the localtestrun.testrunconfig. The paths are rewritten before the mstest is executed, so mstest can find the correct files and assemblies.

I'm sure there must be a better way, but with so many things in development, the first thing that works is good enough.

Update: I've posted some of the source code for the utility.


[Tags: msbuild mstest build machine team system unit testing visualstudio]

And there's me merrily using numbers that are bigger than infinity. How silly of me.

I've just come across a new C# operator in version 2.0, thanks to Oliver Sturm: the ?? operator.

It looks quite cool. I've stopped using ?: because it isn't as readable as an if .. then .. else. This might be useful, particularly if a single word could be used to describe it when reading. "Otherwise" is the best I can come up with at the moment, as in "bar = foo ?? 42" can be read "bar equals foo, otherwise 42". There's probably a better word though. Any suggestions?

A handy FAQ about code snippets in Visual Studio. I mention this as I'm bound to forget where I found it.

Via Daniel Moth.

I would like to recommend bloglines to you. Bloglines is a free and fantastic website that keeps track of weblogs. Users can "subscribe" to weblogs in bloglines, and these appear in a list on a single page. Clicking on a weblog name in the list will show the latest posts in a pane on the right of the list. Bloglines keeps track of which posts you've read, and will highlight the weblog when new posts.

It saves loads of time, as you don't have to visit all the websites separately: bloglines aggregates it all, and lets you know which ones have new content, and which haven't changed since your last visit.

This post is so boring, even I'm not going to read it.

I was just thinking about performance testing, and wondered if writing a unit test would be sensible. If a functional requirement is, for example, "Import all of the data in the crime scene XML file into the database within 0.5 seconds", a test could be written to:

• Get the time into startTime
• Call the ImportCrimeSceneData method
• Get the time into endTime
• Assert endTime < startTime + 0.5 seconds

If this fails, then the ImportCrimeSceneData method can be tuned until it passes. Once it has passed, then any future changes to the method are checked automatically to ensure that the limit isn't exceeded.

Although the idea seems like it would work, it feels like a wrong thing to do. Has anyone else done this successfully, or can anyone give me an actual reason why this is wrong (other than "it just feels like it")?

There's another DDD planned for 22nd October at Microsoft in Reading. The last one was really good, so I intend to go again, even though I've got a gig in the evening.

I feel like a proper blogger at last, as I've just seen the announcement on Craig's site, and I'm blogging it before it made it onto the official site. Jonathan, who did the site for the last one, is probably really busy selling unwanted fondue sets on ebay, so I sneaked in while I had the chance.

They're asking for speakers, which I secretly quite fancy doing, but I don't know enough about anything in particular, so I'm not going to volunteer. Talking to a load of geeks who are much cleverer than me about things I know only a little about sounds like a great way to get blogged about though :-/

Helen, sorry again I gave you no warning about the last one, so here's plenty of notice for the next one.

We've won the 2005 innovation award, for our GlassWorks workflow solution, which is made up of our Glassmatix, WebComms, MIDAS, GlassAudit, eSalvage and MI products.

We have a new company website:

http://www.eurotaxglass.co.uk

Mel Holden: "Common sense isn't that common anymore."

I've just re-read one of my favourite Joel on Software articles, which is about software schedules. Much of it is a load of common sense, and it addresses the main problems with schedules, i.e. being given an unrealistic time estimate, and getting shouted at for not achieving it.

04-07-05_1647.jpg
Originally uploaded by Simon Harriyott.

Wonder what this is.

[Update]: It's a warehouse fire in Paddock Wood.