简体   繁体   English

单元测试控制台c#app的最佳方式

[英]Best way to unit test console c# app

I have a simple console app. 我有一个简单的控制台应用程序 It's fired of with a normal main and the entire program recides in main. 它被普通的主要解雇了,整个程序都在main中。 It uses the Command Line Parser Library . 它使用命令行分析器库 Then I have a second project in the solution containing unit tests for the application. 然后我在解决方案中有第二个项目,包含应用程序的单元测试。 But I don't seem to find a good way to start processes of the main program from the tests. 但我似乎没有找到从测试中启动主程序进程的好方法。 My current code for actually start the process looks something like this. 我当前启动该过程的代码看起来像这样。

...

process = new Process();
process.StartInfo.FileName = "FooBar";
process.StartInfo.Arguments = arguments;

// use it to start from testing environment
process.StartInfo.UseShellExecute = false;

// redirect outputs to have it in testing console
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardError = true;

...

I have tried setting 我试过设置

process.StartInfo.WorkingDirectory

to

AppDomain.CurrentDomain.BaseDirectory

and

Environment.CurrentDirectory;

But do I have to specify the entire relative path for the console applications executable or is there a refined way of starting processes of the "tested" application? 但是,我是否必须为控制台应用程序可执行文件指定整个相对路径,还是有一种改进的方法来启动“已测试”应用程序的进程? First I had my tests as a class in the "main" program and then it worked just fine. 首先,我在“主要”程序中将我的测试作为一个类,然后它工作得很好。 The issues started when I moved the tests to their own project. 当我将测试移动到他们自己的项目时,问题就开始了。 That's why I suspect a path being the issue or something of that nature. 这就是为什么我怀疑道路是问题或者那种性质的东西。

I also tried Running Program.Main but that just feels so wrong :) 我也尝试过运行Program.Main,但这感觉很错:)

I would suggest restructuring your application into: 我建议将您的应用程序重组为:

  • Program - an entry point which parses the arguments, creating a Settings instance Program - 一个解析参数的入口点,创建一个Settings实例
  • Settings - settings for the application (rename according to taste) Settings - 应用程序的设置(根据品味重命名)
  • BusinessClass - (definitely rename!) the actual work, which accepts a Settings instance BusinessClass - (绝对重命名!)实际工作,它接受一个Settings实例

Now you can test things separately: 现在您可以单独测试内容:

  • Test the parsing into Settings , ie are you using the parser library correctly 测试解析为Settings ,即您是否正确使用解析器库
  • Your business logic, where the unit tests create appropriate instances of Settings 您的业​​务逻辑,单元测试创​​建适当的Settings实例

If possible, you should separate your business logic into separate classes for separate concerns of course, and test each separately. 如果可能,您应该将业务逻辑分离为单独的类,以便分别考虑单独的问题,并分别对每个问题进行测试。 We don't really know enough to make concrete suggestions here. 我们真的不知道在这里提出具体的建议。

I don't know why running Program.Main feels wrong for you. 我不知道为什么运行Program.Main对你来说感觉不对。
You're not supposed to unit-test the console mechanism.. only your program's logic, which you can easily do this way. 你不应该对控制台机制进行单元测试..只有你的程序逻辑,你可以轻松地这样做。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM