我应该首先将单元测试编写为控制台应用程序吗？
我正在调试一组 WCF 服务。最初，我创建了一些单元测试，但由于我使用线程，我经常收到“中止”或“停止”测试，而没有任何明确的解释（这是 Visual Studio 中的一个已知错误）。
我发现当我什至无法读取日志输出时调试服务非常具有挑战性，因此我快速编写了一个自定义 Assert 类并将所有单元测试转换为控制台应用程序。通过这种方式，我能够立即解决大量以前很难甚至不可能的简单问题。
所以我想知道首先将单元测试编写为（完全自动化）控制台应用程序，然后将其转换为真实的（在 VS 中启动单元测试时执行）测试是否是一个好主意。
I'm debugging a set of WCF services. Initially, I created some unit tests, but since I'm using threading I often receive "Aborted" or "Stopped" tests without any clear explanation why (this is a known bug in Visual Studio).
I found it extremely challenging to debug the services when I can't even read the log output, so I quickly wrote a custom Assert class and converted all unit tests to console applications. This way, I was able to fix a huge number of simple problems immediately that were hard to impossible before.
So I'm wondering if it is a good idea to write unit tests as (fully automated) console apps first and convert them to real (executes when launching unit tests in VS) tests later.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您想坚持使用独立的控制台应用程序，您可以采用一种万能的方法：将
public static void Main()调用您感兴趣的单元测试。该 exe 可以单独运行，也可以在单元测试 IDE 中运行。
我更喜欢独立的控制台运行程序，如 how-do-i-use- 中所述mstest 无视觉工作室
if you want to stick to the stand alone console app you can have a one fits all aproach: Change
public static void Main()that call your unittests you are interested in.This exe is can run on its own or it runs in the unittest-ide.
I prefer a standalone consolerunner as described in how-do-i-use-mstest-without-visual-studio