如何在解决方案中进行控制台应用程序的集成测试？

Question

我有一个控制台应用程序（稍后将安装为Windows服务），基本上运行一个无限循环，从队列中读取消息并对该消息执行某些操作。

我想创建一个自动化测试用例来启动端到端的行为测试。我的问题是，在单元测试中启动应用程序的最佳方法是什么？ 我使用Process.Start吗？ 还是可以直接引用Program.cs - static void main并运行它？

有什么想法？非常感谢提供示例代码。

[更新：是的，我知道这是集成测试。我已经分离了业务逻辑的逻辑。集成测试的价值在于以自动化方式执行此操作。它确保所有配置设置都正确，我的程序集版本没有问题，我的日志记录、数据库、队列和缓存访问都在运行等。]

- Raymond

---

理想情况下，您的 Program.cs 中应该有一个类来为您完成工作。因此，您的 Program.cs 只需构造并调用该类上的任何方法即可。这样，如果您的控制台应用程序中有依赖项（例如数据），则可以在单元测试中注入这些依赖项。 - Erik Elkins

如果你在谈论单元测试...那么你是否考虑过为你应用程序中的每个单独类编写测试呢（严格来说）？你不应该将应用程序作为一个整体进行测试，而是要测试其组件。而对于边界情况，你的应用程序（作为黑盒）可能不会/不应该通过测试。至于集成测试，则可以使用Process.Start()来运行你的应用程序，直接调用其类可能会导致测试失败，因为你的测试环境可能对其产生太大的影响。 - Adriano Repetti

Answer 1

当我创建这种类型的设置时，我会将所有工作放在一个单独的DLL中。Windows服务/控制台应用程序在一个小项目中，将大部分工作委托给DLL。大多数功能测试都发生在该DLL上。

为了测试最终的可执行文件，我会启动一个进程（假设您的测试正在生成控制台能够处理的消息，并以一种您的单元测试可以测量的方式进行操作）。

确保您有适当的方式来终止控制台应用程序（例如发送“关闭”消息），并检查进程在您的单元测试中是否实际退出。

如果您有多个单元测试都想要启动控制台应用程序，如果每个单独的测试都启动控制台应用程序，则它们将无法并行运行测试。在这种情况下，让您的测试类负责启动和结束进程，而不是每个单独的单元测试。

- Eric J.

Answer 2

有一篇Code Project的文章提到了使用条件编译进行调试：

static class Program
{
    static void Main()
    {
        #if(!DEBUG)
           ServiceBase[] ServicesToRun;
           ServicesToRun = new ServiceBase[] 
       { 
            new MyService() 
       };
           ServiceBase.Run(ServicesToRun);
        #else
           MyService myServ = new MyService();
           myServ.Process();
           // here Process is my Service function
           // that will run when my service onstart is call
           // you need to call your own method or function name here instead of Process();
        #endif
    }
}

- Axel Kemper

---

他（可能）已经在做那件事了。他的问题是如何测试程序，而不是如何将其编译为服务还是控制台应用程序。 - Eric J.

Answer 3

是的，如果你将其设置为公共的，你可以引用 .exe 并调用 main：

public class Program
{
    public static int Main(string[] args)
    {
        // Implementation here...
    }
}

正如其他人所指出的那样，这不会是一个单元测试。

- Mark Seemann