【问题标题】:Run unit test before check in签入前运行单元测试
【发布时间】:2012-10-10 11:15:42
【问题描述】:

使用 Visual Studio 和 TFS,最好使用 Specflow 或标准单元测试。

我希望开发人员在签入之前将所有单元测试作为策略运行。如果单元测试中断,那么 vS 应该阻止他们签入,就像遇到合并冲突时一样。

我知道有后期构建脚本可以做到这一点,但如果单元测试中断,我宁愿它根本不会进入源代码控制。另外,等待完整构建的转身相当慢。然后是关于谁打破谁的东西的争吵。

所以不,我希望在签入之前在本地通过单元测试。我该怎么做?是的,他们可以直接按下按钮,但我希​​望他们比这更“激励”。

【问题讨论】:

  • 我真的不知道你在这里问什么。
  • 所以不,我希望在签入之前在本地通过单元测试。我该怎么做?
  • 我没有反对“他们可以按一下按钮”。
  • 我真的不知道你在这里问什么
  • 是的,我认为这很明显。

标签: c# visual-studio unit-testing tdd bdd


【解决方案1】:

听起来您所追求的是TFS 门控签到。这可以确保代码构建、合并以及测试在提交签入之前成功运行。您可以在此处阅读更多信息:

An introduction to gated check-in

值得注意的是,它比 CI 构建要慢得多,因此根据您的开发人员进行的签入次数,您最好查看启用了“在失败时创建工作项”和项目的 CI 构建设置警报以通知开发人员他们破坏了构建。

【讨论】:

    【解决方案2】:

    【讨论】:

    • 是的,这就是我所说的流程,我看看是否合适。
    • 这是答案,但行不通:(我们在 TFS 上投入了太多。
    • 您可以使用 TeamCity 进行持续集成,并将 TFS 视为版本控制系统。所以它不需要替换TFS,只需补充它。
    • 是的,我们走了那条路。我们有 TFS,但我们花了几天时间试图让 CI 工作。 TeamCity 是几个小时。所以 TFS 仅用于源代码控制。
    猜你喜欢
    • 2011-05-05
    • 1970-01-01
    • 2012-11-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多