【问题标题】:TeamCity incremental testing for .Net projects.Net 项目的 TeamCity 增量测试
【发布时间】:2014-10-13 16:15:23
【问题描述】:

我正在构建一个模块化 WPF 应用程序。每个屏幕都是一个高度独立和孤立的单元。唯一共享的东西 - shell 和一个带有外观接口的公共库,用于可重用服务(消息总线、持久性、窗口管理等)。

由于模块是松散耦合的,因此当单个模块发生更改时重新测试所有内容是没有意义的。我只想测试发生了什么变化。如果公共库发生变化 - 一切都应该重新测试。

从源代码控制差异中,您可以轻松获取更改的文件列表,从而解决受影响的项目(csproj 文件列出了所有要编译的文件)。您还可以从 csproj 文件(谁在使用它,谁受到影响)解决项目依赖关系。所有这些信息应该足以说明实际需要测试的内容。所以这个问题听起来是可以解决的。

有人用 TeamCity 做过这个吗?有什么建议?我看到有一个适用于 Java 人员的解决方案: http://blog.jetbrains.com/teamcity/2012/03/incremental-testing-with-teamcity/

.net 领域呢?

【问题讨论】:

    标签: c# .net msbuild nunit teamcity


    【解决方案1】:

    您必须创建构建配置并生成工件并运行测试。

    例如,您有项目 LibraryLibrary.TestsPortablePoratble.TestsAppApp.Tests

    您必须创建编译LibraryLibrary.Test 项目的构建配置(例如Library build)。此配置会生成伪像,例如。 libtests.zip.

    然后您创建另一个构建配置(例如Run Library Tests 并在先前创建的Library build 配置上设置快照和工件依赖项。在此测试运行配置中,您需要解压libtests.zip 文件(从工件依赖项收集)并创建一个构建步骤(例如 NUnit runner)来运行这些测试。

    请注意:您只想在库中发生更改时运行测试,因此在“版本控制设置”下检查Show changes from snapshot dependencies 并创建将Trigger on changes in snapshot dependencies 的新VCS 触发器(也是一个复选框)。

    然后,让我们假设 Portable 依赖于 Library 并拥有自己的测试套件。

    同样,您应该创建构建配置,该配置将编译项目PortablePortable.Tests 并生成名为例如。 portabletests.zip

    你再次创建另一个构建配置来运行这个测试,就像以前一样。只有这一次您应该在Build libraryRun library tests 配置上添加另一个快照依赖项。通过这个额外的快照依赖,您将实现代码仅在库构建和测试运行正常时编译和运行。

    AppApp.Tests 也是如此。

    所以...当库中发生更改时,将重新构建整个集合并运行所有测试(Library.TestsPortable.TestsAppApp.Tests)。 当Portable 代码发生更改时,将触发Bulid portables 并运行Portable.Tests 并重新编译App + App.Tests 并运行App.Tests

    在此链接上,您可以了解有关 teamcity 中快照和工件依赖项的更多信息 http://confluence.jetbrains.com/display/TCD8/Configuring+Dependencies

    【讨论】:

    • 谢谢!这个解释非常有用。我不确定的一件事是需要手动定义依赖项,为每个模块配置构建。感觉很多手工活。项目文件具有自动生成构建项目结构(teamcity 配置)的所有元数据。如果我知道输出结构和格式,我可以自己为此编写一个脚本。
    • 根据我的个人经验,我不建议这样做。在 teamcity 中手动设置依赖项是可行的方法,您不必构建单个 C# 项目 (csproj)。例如。前面提到的“库构建”可以并且应该包含多个 C# 项目(例如 Library.Caching、Library.Controls...)
    • 为什么不呢?最大化未完成的工作量。在我的情况下,“图书馆”是一个单一的项目,它不太可能分裂。没有实际的理由来划分它。我不喜欢过多考虑未来(如果有人想重用它怎么办)。我猜错的可能性更大。有问题就出问题。
    • 90% 的时间我只更改一个屏幕而不接触共享代码。这是主要问题。跟踪共享源中的更改并触发依赖项的重建也很重要。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-04-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-10-16
    • 2017-10-18
    • 2011-08-09
    相关资源
    最近更新 更多