3

I've developed a large base of unit tests for my company's application, and dev would like to hand my unit tests over to our support department to help them debug customer installation problems. I wrote my unit tests using mstest, so support would have to install Visual Studio on a customer's machine if they wanted to use my tests out of the box, which is the wrong thing to do, obviously. I have looked into using mstest without VS at the command prompt, but hacking the registry on a customer's system to make it think VS is installed isn't workable either.

To get around this I planned on compiling my mstests for nunit using the information in this post . However, after compiling with NUnit enabled, and adding my test assembly dll to the NUnit runner, I get the error message "This assembly was not built with any known framework."

Has anyone done this and has tips/tricks to get this running? Or is this the entirely wrong way to go about solving this problem? Thanks.

Community
  • 1
  • 1
Case
  • 1,848
  • 21
  • 32
  • To me this seems a doable 'solution': Extract the core/contents of all unit tests, put them in a separate class library solution, to be able to distribute it. Of course you have to then separate the Assert.Functions from the class library solution. Call the externalized functions from your unit test code or from your external test tool. So the class library becomes the core, and the MSTest framework, or your own external test tool, become the 'GUI' wrappers. This requires some refactoring/rewriting of course, but the actual tests stay the same, don't they? – Mike de Klerk Feb 24 '14 at 14:03

2 Answers2

1

I'm going to go with your second thought on this "Or is this the entirely wrong way to go about solving this problem".

To solve this problem easily and not confuse your support department I would recommend creating a little command-line wrapper around the test class. You can write the command-line tool yourself, or if you prefer you can do the following:

using CSharpTest.Net.Commands;
static void Main(string[] args)
{
    MyTest testClass = new MyTest();
    // optional: testClass.MySetupMethod();
    new CommandInterpreter(testClass).Run(args);
}

Just build the above code as a command-line exe in a new project referencing your test assembly and CSharpTest.Net.Libary.dll. The namespace CSharpTest.Net.Commands is defined in the CSharpTest.Net.Libary.dll assemby from this download.

Essentially the above code will crawl your test class (named MyTest in the example above) and expose all the public methods as commands that can be executed via the command line. By default it provides help output and sets the Environment.ExitCode on failure. If you want to get fancy you can decorate your tests with any of the following:

public class MyTest
{
    [System.ComponentModel.DisplayName("rename-this-function")]
    [System.ComponentModel.Description("Some description for tech-support")]
    [System.ComponentModel.Browsable(true | false)]
    public void TestSomeFunction()
    { ... }
}

(And yes I acknowledge I am shamelessly plugging my own code a wee-bit :)

csharptest.net
  • 62,602
  • 11
  • 71
  • 89
  • Interesting. I've gone down this a bit since yesterday, whipping up a small console app that used reflection to call the test methods in my class, but ran into problems with TestContext and the class initialization methods. Looks like you build your initializers yourself per test run? – Case Oct 06 '09 at 21:23
  • 1
    Ahh, no I forgot about MsTest's weird initialization dependencies. I think they did it intentionally to force you to keep using MsTest :) Anyway, can you break your dependencies on the MsTest specific stuff? If not, I would have to retract my original recommendation and suggest you write a command-line utility apart from the tests. Just keep it automated in the build in parallel with the tests to ensure it continues to work. – csharptest.net Oct 06 '09 at 23:22
  • This is the closest answer to what I ended up going with - which was just another version of my code that ran on NUnit with a subset of the tests. – Case Jul 14 '11 at 01:50
1

My concern would be someone adding a unit test (or integration test disguised as a unit test) which you inadvertently run against your customer database. Of course I'm making assumptions such as you having a database, but it seems a risky approach unless you can be sure that your tests are non-destructive, now and in the future.

Do you have logging in your application? That's the traditional way to help support, and there are many tools out there to help you.

si618
  • 16,580
  • 12
  • 67
  • 84