Stories about Software


MS Test Report Generator

I’ve been working on a side project for a while, and today I uploaded it to Source Forge. The project is a tool that takes XML results generated by MS Test runs and turns them into HTML-based reports. I believe that TFS will do this for you if you have fully Microsoft-integrated everything, but, in the environment I’m currently working in, I don’t.

So I created this guy.

Back Story

I was working on a build process with a number of constraints that predated my tenure on the process itself. My task was to integrate unit tests into the build and have the build fail if the unit tests were not all in a passing state. The unit test harness was MS Test and the build tool was Final Builder.

During the course of this process, some unit tests had been in a failing state for some period of time. Many of these were written by people making a good faith effort but nibbling at an unfortunate amount of global state and singletons. These tests fail erratically and some of the developers that wrote them fell out of the habit of running the tests, presumably due to frustration. I created a scheme where the build would only run tests decorated with the “TestType” attribute “Proven”. In this fashion, people could write unit tests, ‘promote’ them to be part of the build, and have it as an opt-in situation. My reasoning here is that I didn’t want to deter people who were on the fence about testing by having them be responsible for failing the build because they didn’t know exactly what they were doing.

After poking around some, I saw that there was no native final builder action that accomplished what I wanted– to execute a certain subset of tests and display a report. So I created my own batch scripts (not included in the project) that would execute the MS Test command line executable with filtering parameters. This produces an XML based output. I scan that output for the run result and, if it isn’t equal to “Passed”, I fail the build. From there, I generate a report using my custom utility so that people can see stats about the tests.

Report Screenshot


During the course of my spare time, I decided to play around with some architectural concepts and new goodies added to C# in the .NET 4.0 release. Specifically, I added some default parameters and experimented with co-variance and contra-variance. In terms of architecture, I experimented with adding the IRepository pattern to an existing tiered architecture.

On the whole, the design is extensible, flexible, and highly modular. It covered about 99.7% by unit tests and, consequently, was complete overkill for a little command line utility designed to generating an HTML report. However, I was thinking bigger. Early on, I decided I wanted to put this on Source Forge. The reason I designed it the way I did was to allow for expansion of the utility into a GUI-driven application that can jack into a server database and maintain aggregate unit testing statistics on a project. Over the course of time, you can track and get reports on things like test passing rate, test addition rate, which developers write tests, etc. For that, the architecture of the application is very well suited.

The various testing domain objects are read into memory, and the XML test file and HTML output file are treated as just another kind of persistence. So in order to adapt the application in its current incarnation to, say, write the run results to a MySQL or SQL server database, it would only be necessary to add a few classes and modify main to persist the results.

Whether I actually do this or not is still up in there air, and may depend upon how much, if any, interest it generates on Source Forge. If people would find it useful, both in general and specifically on projects I work on, I’m almost certain to do it. If no one cares, I have a lot of projects that I work on.

How to Access

You can download a zipped MSI installer from SourceForge.

If you want to look at the source code, you can do a checkout/export on the following SVN address: https://mstestreportgen.svn.sourceforge.net/svnroot/mstestreportgen

That will provide read-only access to the source.



One of the things that I take for granted and figured that I probably ought to document is a tool called Synergy (or now, Synergy+, apparently). Found here, this is a tool that is perfect for someone who wants to control multiple computers on a desktop without having to deal with the inconvenience of swapping between multiple keyboards and/or mice. In this fashion, it is a “KM solution” (as opposed to the typical KVM switch). Here is a screenshot of what my office looks like:

My home office

The left monitor and center monitor are attached to a computer running Windows XP. The right monitor is running Fedora and attached to my home server, and the netbook is running the Ubuntu netbook remix. It’s hard to depict, but I’m controlling all three computers with one keyboard and mouse. When I move the mouse off the left edge of the left-most monitor, it goes to the center monitor. This is done by Windows XP itself. When I move the mouse off the right edge of the center monitor, it goes to the right-most monitor running Fedora, and I can then operate that machine as I normally would. When I move the mouse off the bottom of the Fedora monitor, it goes to the netbook.

The netbook is something that I don’t always have there, and Synergy is ‘smart’ enough to figure out how to handle this. If a machine isn’t actively participating, it removes the transitional border. So, if I turn the netbook off, moving the mouse to the bottom of the Fedora server’s screen doesn’t put me in empty space — it behaves as it would without Synergy, for that particular edge. (Things can get a little interesting if I take the netbook elsewhere in the house and forget to turn off Synergy.)

So, how is this accomplished? Well, Synergy must be installed on all participating computers. This is easy enough. For windows, there is an installer that can be downloaded. For Ubuntu, a “sudo apt-get install synergy” should do the trick. For Fedora, “yum install synergy” (with elevated privileges) should do the same. You can do it on any flavor of Linux you like and on a Mac as well.

Next, you need to pick which machine will be the server and which machine(s) will be the client. As a rule of thumb, I would suggest using the machine that you use the most and/or is on and active the most as the server. This will be the computer to which the keyboard and mouse are actually, physically connected. In my case, this is the Windows XP computer (I don’t use the server nearly as often, and anything that gets me out of using laptop keyboards is great). Once installed, starting the clients on other machines is easy. For instance, on both Linux machines, I just type “synergyc” from the command line, and they’re all set to be controlled. The Linux installations have a graphical tool like Windows as well, but as I’ve mentioned before, I tend to favor the command line–particularly in Linux.

The server setup is slightly more complicated, but not bad. If you start the synergy graphical screen, you will have some navigation options. Select “share this computer’s keyboard and mouse (server)” and then click the Configure button below. You will see a screen like this:

Configure Synergy

The first thing to do is to add the screens using the “+” key under “screens.” This is pretty straightforward. Ignoring the options (you can play with these later), it simply wants the workgroup or domain name of the computer to which the monitor is attached. If you have a hodgepodge of OS and haven’t used something like Samba to resolve the naming, you can use their IP addresses and then, if you want, give them aliases to make it a little more descriptive.

In my example, the Windows PC is called “achilles,” the Fedora server is called “Homeserver,” and the netbook is called “echo.” As you can see, relationships are defined between each monitor. X is to the left of Y, and Y is to the right of X, for instance. It is important to specify both sides of the relationship. If you only specify one, the other is not inferred. So if I just specified that Homeserver was to the right of achilles, Synergy would move my mouse from the Windows machine to the Fedora server but never move it back.

Notice the percentages at the bottom. These allow you to specify that only part of the screen passes through. You can use this if, for example, one monitor is substantially larger than the one next to it, and you want to create a logical flow. You might specify that only half of the larger monitor passes through to its neighbor. It is, in fact, possible to create some very weird and convoluted configurations if you choose. You could do something like in one of those crime drama shows where the techie character has eight monitors with two or three different rows vertically.

The real, practical use here is that you can dispense with multiple keyboards and mice and you can do it regardless of the OS running on the various machines. The only requirements for this to work are that the machines have to be connected on the same local network and that the machines each need their own monitor/display. If you are running Synergy and a machine loses connectivity, it will stop working.

And, in this same vein, a word of caution. Synergy works by sending your mouse gestures and typed text across the network, in plain text. That is to say, you wouldn’t want to set this up in a hotel or coffee shop because someone with a sniffer could read everything that you’re typing, including your login passwords for anything to which you sign in. So this is mainly a product for your home network, assuming that you don’t have some adversarial techie in the house interested in spying on you. I’m not specifically aware of any plans on the part of the tool’s authors to offer an encrypted version, but if that does happen, I will likely be excited enough to post about it.

If anyone is interested in more specifics of setup and has questions, feel free to post them.