Visual Studio如何自动构建和测试C＃代码？

Question

我已经习惯了Eclipse for Java项目，每当我保存文件时它都会自动构建。 （我可以关掉它。）

然后我安装Infinitest，它会自动运行受保存更改影响的所有测试。

我是如何为Visual Studio编写的，编写C＃软件？

Answer 1

VS 2017企业版支持Live Unit Testing功能。对于旧版本或更低版本，可以使用某些第三方提供商，例如Mighty Moose或NCrunch（其他第三方解决方案也几乎肯定存在）

Answer 2

Important note:

如果您只关心C＃/ .NET代码并且只想运行单元测试，那么此功能已经存在于Visual Studio 2017（仅限企业版）中，称为实时单元测试，请在此处阅读更多相关信息：https://docs.microsoft.com/en-us/visualstudio/test/live-unit-testing-intro?view=vs-2017

实时单元测试是Visual Studio 2017 15.3版中提供的一种技术，可在您进行代码更改时自动执行单元测试。

My original answer:

（我曾经是Microsoft在Visual Studio上工作的SDE（2012年，2013年和2015年）。我自己没有在构建管道上工作，但我希望我能提供一些见解:)

Visual Studio如何自动构建和测试代码？

它没有，在我看来，它不应该，假设“构建和测试代码”，你的意思是它应该执行标准的项目构建，然后运行测试。

Eclipse仅构建受更改影响的内容。奇迹般有效。

甚至增量构建也不是即时的，特别是如果有重要的后编译活动（例如复杂的链接和优化（甚至在调试模式下），外部构建任务（例如嵌入资源，可执行压缩，代码签名等）。

特别是在Eclipse中，这个功能并不完美。 Eclipse主要是一个Java IDE，在Java项目中，很有可能非常快速地执行增量构建，因为无论如何Java的构建时间非常快，而增量构建就像在Java .class中交换嵌入式.jar文件一样简单。在Visual Studio中，为了进行比较，.NET程序集的构建时间也很快 - 但不是那么简单，因为输出PE（.exe / .dll）文件不像重建那么简单。

但是在其他项目类型中，尤其是C ++，构建时间要长得多，因此为C / C ++开发人员提供此功能是不合适的，事实上Eclipse自己的文档建议C / C ++用户关闭此功能：

https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_autobuild.htm

默认情况下，Eclipse工作台配置为自动构建项目。但是，对于C / C ++开发，您应该禁用此选项，否则只要您将更改保存到makefile或源文件，就会重建整个项目。单击“项目”>“自动构建”，并确保“自动构建”菜单项旁边没有复选标记。

其他项目类型也不支持此功能，例如Eclipse的Go插件：

https://github.com/GoClipse/goclipse/releases/tag/v0.14.0

0.14.0的变化： [...]当工作空间“自动构建”设置已启用并保存文件时，不再调用项目构建器。 （这被认为是错误的）

（这个括号内容在GoClipse的更改列表中，当然也清楚说明了插件的作者对自动构建的看法）

然后我安装Infinitest，它会自动运行受保存更改影响的所有测试。

Visual Studio可以在构建后自动运行测试（但您仍然需要自己触发构建），这是一个内置功能，请参见此处：

https://docs.microsoft.com/en-us/visualstudio/test/run-unit-tests-with-test-explorer?view=vs-2017

要在每次本地构建后运行单元测试，请在标准菜单上选择“测试”，然后在“测试资源管理器”工具栏上选择“运行后运行测试”。

至于我为什么Visual Studio不支持Build-on-Save的原因：

• 只有最简单的C＃/ VB和TypeScript项目在不到一秒的时间内构建，其他项目类型，如C，C ++，SQL数据库等，需要几秒钟才能完成简单项目的热重建 - 对于大规模C ++而言需要几个小时在单核CPU，低RAM和5400rpm IDE硬盘驱动器上有大量导入标题的项目。
• 许多构建都是IO密集型的（特别是带有大量头文件的C / C ++项目*咳嗽*，如<windows.h> * cough *），而不是受CPU限制，而磁盘IO延迟是导致其他版本锁定和减速的主要原因。计算机上运行的应用程序，因为磁盘分页操作可能会延迟，或者因为它们正在GUI线程上执行磁盘IO操作，等等 - 所以在磁盘IO大量构建中启用此功能只会意味着您的计算机将抖动每次按Ctrl + S或自动保存运行时都会进行很多操作。
• 并非每个项目类型都支持增量构建，或者可以支持快速增量构建。 Java是此规则的一个例外，因为Java的设计使得每个输入源.java文件都将1对1映射到输出.class文件，这使得增量构建非常快，因为只需要重建实际修改的文件，但其他项目如C＃和C ++没有这种奢侈：如果你对C预处理器宏或C ++模板进行无关紧要的单字符编辑，你需要重新编译使用该模板的所有其他内容 - 然后是链接器和优化器（如果代码） -inlining）都必须重新运行 - 而不是一个快速的任务。
• 构建可能涉及删除磁盘上的文件（例如清理构建输出文件夹）或更改全局系统状态（例如写入非项目构建日志） - 在我看来，如果程序删除了我目录下的任何内容个人拥有（例如C:\git\或C:\Users\me\Documents\Visual Studio Projects）它最好还是要求我每次直接允许这样做 - 特别是如果我想在做某事的时候做最后一次构建输出的事情。我不想首先将构建输出复制到安全目录。这也是“清洁项目”命令是独立的，而不是“构建项目”所暗示的原因。
• 用户经常每隔几秒就按Ctrl + S（我就是其中一个人） - 即使我在编辑器中编写了不完整的代码，我也按下Ctrl + S：语法错误甚至是破坏性代码 - 我不知道想要构建完全代码，因为它还没有准备好构建！即使我的代码中没有错误，IDE也无法推断我的意图。
• 构建项目是获取代码库错误列表的一种方法，但几十年来一直没有必要：IDE长期存在设计时错误和警告而无需编译器运行构建（感谢语言之类的东西）服务器） - 实际上运行构建只会在IDE的错误窗口中给出双重错误消息，因为我已经有来自设计时错误列表的错误消息。
• Visual Studio，至少（我不能代表Eclipse）在构建期间进入一种特殊的只读模式：因此在构建过程中无法保存对磁盘的进一步更改，您无法更改项目或IDE设置，等等 - 这是因为构建过程是一个漫长的过程，它依赖于项目源处于固定的已知状态 - 如果源文件被修改，编译器就无法完成其工作读他们！因此，如果IDE在每次保存后始终构建（即使只是几秒钟），用户也不会喜欢IDE在构建完成之前如何阻止它们执行某些编辑任务（请记住，IDE不仅仅是显示编辑器：某些专用工具窗口可能需要写入项目文件才能打开）。
• 最后，Building并没有副作用（事实上，这就是重点！） - 在构建过程中总会存在一些可能出错的风险并且会破坏系统中的其他内容。我并不是说构建是冒险的，但是如果你有一个自定义构建脚本，它会冒一些风险（例如它运行TRUNCATE TABLE CriticalSystemParameters）并且构建中断（因为它们总是这样做），它可能会使你的系统处于不良状态。
• 此外，还有（略带哲学）问题：“如果您对项目的构建脚本保存不完整的更改，会发生什么？”。

现在我承认一些项目类型的构建非常非常快，如TypeScript，Java和C＃，而其他项目类型的源文件根本不需要编译和链接，只需运行验证工具（如PHP或JavaScript） - 并且Build-on-Save可能对那些人有用 - 但可以说，对于那些经验有所改善的人数有限，这显然会使其他用户恶化。

如果你真的想要build-on-save，那么编写Visual Studio的扩展（挂起“File Save”命令，然后在你的处理程序中调用Project Build命令）就足够了 - 或者养成按Ctrl键的习惯Ctrl + S后+ B :)