Visual Studio如何自动构建和测试C#代码?

Rog*_*son 5 visual-studio visual-studio-2017

我习惯了Eclipse for Java项目,该项目在保存文件时会自动生成。(我可以将其关闭。)

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

对于编写C#软件的Visual Studio,我该如何做?

Dai*_*Dai 5

重要的提示:

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

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

我的原答案:

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

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

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

Eclipse 只构建受更改影响的部分。奇迹般有效。

即使是增量构建也不是即时的,尤其是在有重要的编译后活动(例如复杂的链接和优化(即使在调试模式下)、外部构建任务(例如嵌入资源、可执行压缩、代码签名等)的情况下)。

在 Eclipse 中,具体来说,这个特性并不完美。Eclipse 主要是一个 Java IDE,在 Java 项目中,很有可能非常快速地执行增量构建,因为无论如何 Java 的构建时间都非常快,而且增量构建就像.class在 Java 中交换嵌入文件一样简单.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 或源文件的更改时重建。单击 Project > Build Automatically 并确保 Build Automatically 菜单项旁边没有复选标记。

其他项目类型也不支持此功能,例如 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

要在每次本地构建后运行单元测试,请Test在标准菜单上选择,然后Run Tests After Build在测试资源管理器工具栏上选择。

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

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

现在我承认有些项目类型确实构建得非常非常快,如 TypeScript、Java 和 C#,而其他项目类型的源文件根本不需要编译和链接,只需运行验证工具(如 PHP 或 JavaScript)——并且拥有Build-on-Save 可能对这些人有用——但可以说,对于少数人来说,它改善了它的体验,显然会使其他用户的体验变得更糟。

如果你真的想要在保存时构建,那么编写 Visual Studio 的扩展就足够了(挂钩“文件保存”命令,然后在你的处理程序中调用项目构建命令) - 或者养成按Ctrl+B之后的习惯Ctrl+S:)


Dam*_*ver 4

VS 2017 企业版支持实时单元测试功能。对于旧版本或较低版本,可以使用一些第三方提供商,例如Mighty MooseNCrunch(几乎肯定也存在其他第三方解决方案)