问题:.NET 中用于编写验收测试的最新维护最多的框架是什么? [关闭]

我现在练习 TDD 有一段时间了,我想提高我的技能并开始做 ATDD,我阅读了 ruby 和 java 的框架,但没有听到太多关于 .NET 的信息

.NET 中用于编写验收测试的维护最多的最新框架是什么?

编辑:在阅读更多内容后,我想指出我正在将网站和 Web 应用程序的验收测试联系起来,任何可能它也必须被视为 GUI 测试。

解答

我们刚开始使用FitNesse,到目前为止我对这个决定感到满意。一个非常简短的概述:

1. 您在 Wiki 中编写测试。

2. 您编写了一个“测试夹具”模块(可以是 c# 程序集),它提供了 Wiki 中的“测试”和 SUT(被测系统)之间的桥梁。

3. 当您运行测试时,FitNesse 引擎使用反射将 wiki 测试转换为对测试夹具组件的调用,进而调用 SUT。返回值被传递回 Wiki,因此您可以“断言”它们。

测试夹具代码的公共接口实际上是您在 Wiki 中编写测试所使用的语言。我不确定我是否解释得很好,但是网络上有很多资源和视频。我推荐这一款来自 FitNesse 的作者 Bob Martin。

我选择 FitNesse 有几个原因:

• 完善的框架

• 使用 FitSharp 插件与 .NET 一起工作:http://fitnesse.org/FitNesse.DotNet

• 因为 Wiki 中的测试是用您在夹具代码中定义的语言编写的,所以它们是可读的

• 测试可以通过命令行调用,这是我们想要的持续集成。

• Robust 1:如果SUT的接口发生变化,您只需要更改测试夹具代码,而不是测试

• Robust 2:我们没有在 volatile UI 级别进行测试。

这需要一点时间来适应,但我发现它比我们目前通过 UI 进行测试的概念要可靠得多。我们目前在自制应用程序中执行此操作,该应用程序通过回放预先录制的 UI 操作和比较屏幕截图来工作。当测试为红色时,很少是因为 SUT 实际上已损坏。通常我们会遇到 UI 控件无法立即做出反应的时间问题,因此我们必须在 UI 操作之间建立延迟,这意味着运行全套测试需要整晚。