【问题标题】:Infrastructure required for TDD?TDD 所需的基础设施?
【发布时间】:2009-12-14 18:31:14
【问题描述】:

我对单元测试和 TDD “相对较新”。直到最近,我才完成了我的第一个(至少在理论上)100% 代码覆盖率的生产应用程序。我在以前的项目中也做过一段时间的单元测试,但不是以真正的 TDD 方式并且具有良好的代码覆盖率。这一直是事后的想法。不过我觉得我现在已经掌握得很好了。

我还在尝试对团队的其他成员进行 TDD 和单元测试方面的培训,以便我们能够共同成长并开始在我们所有的应用程序中进行单元测试,并最终进展到完全自动化的 TDD构建和持续集成。我发布了a thread here 关于我针对 cme​​ts 和批评的攻击计划/培训议程。

其中一个回复(实际上是投票率最高的)建议我先设置基础架构,然后再进行培训。不幸的是,我没有接触过这个,并且在谷歌上搜索这些主题很困难,因为 CruiseControl.NET / nAnt / 等的页面并没有真正解释我们应该设置它的“原因”以及所有东西如何连接在一起。

我们是一家小商店(大约 10 名开发人员),几乎完全使用微软技术,并在 VB.NET 中进行开发。我们希望最终开始使用 C#,但那是另一次了。我一直在使用 VS2008 附带的 MSTest 项目进行单元测试,我一直在使用 Visual Studio 构建我的应用程序,并使用 MSI 设置项目进行部署......我们也(不幸的是)使用 VSS 进行我们的源控制 -但这也是在砧板上,我真的很想摆脱它并使用颠覆。

我知道我需要将 CruiseControl.NET 用于 CI,并使用 nAnt 或 MSBuild 来构建应用程序。而且我可能需要一个构建服务器来运行所有这些构建。但我只是找不到任何“连接”这些点并解释它们如何相互交互、构建服务器上应该有什么、何时应该使用构建服务器构建(它只是用于部署构建,还是当你只是想在本地环境中进行一些小改动后编译您正在开发的应用程序?)。我还计划取消 MSTest,因为我发现它有问题,将改用 nUnit。

谁能说明我从“知道如何进行 TDD”到“设置适当的基础架构以便整个团队能够做到并一起工作”之间的差距?我确实了解什么是持续集成,但我也不确定应该如何设置构建服务器以及它如何与所有东西连接,以及为什么我们需要一个(例如,向管理层推销)。

非常感谢您的宝贵时间。

我需要 finalbuilder 的哪一部分? 看来 final builder 和 teamcity 有一些重叠。 Finalbuilder 服务器似乎是 CI 服务器,所以我猜我不需要它。 FinalBuilder 似乎是一个构建服务器 - 但我认为 TeamCity 也是一个构建服务器......而 Automise 似乎是一个可视化的 windows 自动化工具,就像某种用于 winforms 应用程序的开发平台......

_在The Team City Supported Apps Diagram 中我也没有看到对最终构建器的支持:_

【问题讨论】:

标签: tdd build-process continuous-integration


【解决方案1】:

看看我几周前举办的网络研讨会 - How To Start Unit Testing Successfully。在那次网络研讨会中,我谈到了工具和单元测试的最佳实践,它面向像您这样想要在他们的组织中引入单元测试的开发人员。

您希望实施 CI(持续集成)流程的第一个业务订单,为此您需要三个工具:

  1. 源代码控制
  2. 构建服务器
  3. 构建客户端/脚本

我希望你已经有了某种形式的源代码控制,所以让我们谈谈另外两个。

构建服务器 - 检查源代码控制,当它发生变化(或满足其他条件)时,在某个客户端(或同一台机器)上运行构建脚本,有几个构建服务器可用我推荐 JetBrain 的 @ 987654322@ 它易于安装和使用(出色的网络界面),最多可免费供 20 位开发人员(即您)使用。

构建脚本 - 在您的构建客户端上,您希望运行构建脚本来构建您的解决方案并运行您的单元测试。 TeamCity 具有一些基本的构建和测试功能,但对于更高级的选项(构建安装程序、文档等),您需要一些脚本运行程序,我们使用FinalBuilder - 它不是免费的,但有非常好的编辑器。如果您正在寻找免费的替代方案,请查看 ANTNANT - 但请准备好编辑大量 XML。

其他工具 - 因为成功的单元测试的一个重要部分是在开发人员的机器上编写和运行测试是多么容易,所以我建议您检查是否有更好的 IDE 或外部工具可以提供帮助开发人员编写并运行他们的单元测试。

【讨论】:

  • +1 代表 TeamCity。我们从 CruiseControl.NET 开始并切换到 TeamCity,因为它更易于管理。 NAnt 脚本非常容易编辑,但您无需使用 TeamCity 进行太多操作。
  • 非常感谢您提供的信息。我编辑了我的原始帖子以说明我们使用 VSS。虽然我讨厌 VSS =)。我希望得到颠覆设置,这样我们就可以最终摆脱那个有问题的 VSS。不过,我确实有一个问题 - 您是否在开发时使用您的构建服务器来编译您自己的本地构建?还是仅用于部署构建?
  • 我确实在本地机器上运行构建脚本,但通常 VS 足以构建和测试我的项目
  • 您是否曾经将 VSS 用作基础架构的一部分?这是一个我讨厌的错误 POS(笑)。无论如何,我希望我们转移到 Subversion/VisualSVNServer/VisualSVN。但是我正在尝试决定我们是否应该在任何事情之前先进行源代码控制,还是可以在之后进行?...或者前者是否会因为 SS 与上述工具紧密耦合而导致问题? VSS 与上面提到的这些工具配合得很好吗?我假设必须至少有一些小问题——见鬼;它甚至不能与 Visual Studio 配合使用! ;)...再次感谢您的帮助
  • 首先,我认为 VSS 与 TeamCity 配合得很好,而且我知道 FinalBuilder 支持它。话虽如此,我更喜欢使用 P4 或 SVN,因为它们工作得更好(至少对我而言)。您可以随时在项目后期更改源代码控制工具,但这会很痛苦。如果您想切换源代码控制,我建议您在决定后立即进行。做一个简单的峰值 - 保留 VSS 并尝试移动到不同的源代码控制,如果它工作转储 VSS。
猜你喜欢
  • 2016-04-26
  • 1970-01-01
  • 2023-03-20
  • 1970-01-01
  • 2011-06-19
  • 2013-03-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多