对客户的安装进行单元测试(使用 NUnit 和 MSTest)

发布于 2024-08-06 16:34:43 字数 290 浏览 2 评论 0原文

我已经为我公司的应用程序开发了大量的单元测试,开发人员希望将我的单元测试交给我们的支持部门,以帮助他们调试客户安装问题。我使用 mstest 编写了单元测试,因此如果支持人员想要开箱即用地使用我的测试,那么支持人员必须在客户的计算机上安装 Visual Studio,这显然是错误的做法。我已经研究过在命令提示符下使用没有 VS 的 mstest,但是破解客户系统上的注册表以使其认为 VS 已安装也是行不通的。

为了解决这个问题,我计划使用

有没有人做过这个并且有提示/技巧来让它运行?或者这是解决这个问题的完全错误的方法?谢谢。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

窝囊感情。 2024-08-13 16:34:43

我将同意你对这个问题的第二个想法“或者这是解决这个问题的完全错误的方法”。

为了轻松解决这个问题并且不让您的支持部门感到困惑,我建议围绕测试类创建一个小的命令行包装器。您可以自己编写命令行工具,或者如果您愿意,也可以执行以下操作:

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

只需在引用测试程序集和 CSharpTest.Net.Libary.dll 的新项目中将上述代码构建为命令行 exe。命名空间 CSharpTest.Net.Commands 在 CSharpTest.Net.Libary.dll 程序集中定义 从此下载

本质上,上面的代码将抓取您的测试类(在上面的示例中名为 MyTest)并将所有公共方法公开为可以通过命令行执行的命令。默认情况下,它提供帮助输出并在失败时设置Environment.ExitCode。如果你想变得更奇特,你可以用以下任何一个来装饰你的测试:

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()
    { ... }
}

(是的,我承认我无耻地插入了一点点我自己的代码:)

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 :)

童话 2024-08-13 16:34:43

我担心的是有人添加了您无意中针对客户数据库运行的单元测试(或伪装成单元测试的集成测试)。当然,我假设您拥有一个数据库,但这似乎是一种冒险的方法,除非您可以确定您的测试现在和将来都是非破坏性的。

您有登录您的应用程序吗?这是提供支持的传统方式,并且有许多工具可以为您提供帮助。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文