问题标签 [bdd]

我负责为我的公司重写一个内部工具。我目前正在修改最耗时的步骤以更快地运行，这应该让我有时间重新考虑应用程序的设计以进行完全重写，因为插页式版本将满足当前的需求。

我真的很想借此机会使用 BDD/TDD 来实现这段代码，但我对这种编程方法很陌生，尤其是在 .NET 的上下文中。是否有可用于 .NET 的 BDD/TDD 工具？我应该看哪些资源？

非常感谢您！

阿什什

任何人都可以向我指出一些使用 NUnit 进行 Give-When-Then 测试的资源吗？

我无法让 NCover 正确覆盖 .dll。我有几个使用XUnit.NET和SubSpec来执行 BDD 样式规范的测试项目。除了其中一个之外，所有测试套件都可以在 TestDriven.NET (1.5.8) 附带的 NCover 版本中完美运行。但是，我有一个拒绝分析实际测试的组件。我已经验证了 /a 选项的程序集名称是正确的，.pdb 文件存在，并且在执行过程中没有抛出异常。8 个测试全部通过，在执行 NCover 控制台应用程序时可以看到。

该程序集引用 WPF 程序集PresentationCore、PresentationFramework和WindowsBase。我不确定这是否会导致问题，但我对 NCover 拒绝分析此程序集感到完全困惑。

命令行：

笔记：

问题似乎已经解决了！我不知道发生了什么变化，但组件现在被正确覆盖，并且覆盖率为 100%！感谢你们中提供一些意见的人。我很感激！

在我当前的项目中，我想在业务需求应用程序级别任务的两个级别上使用行为驱动开发 (BDD)。

是否可以将我的内部 BDD 规范包装（分组）到我的高级规范中，以便客户可以看到业务需求已完成（该需求中的所有内部规范都已通过）但实际上看不到我的内部规范？

使用 TDD/BDD 方法开发应用程序时，应该有多精细？特别是关于 Rails 应用程序。

您会单独测试每个字段，然后正确迁移以使其通过吗？那么每个领域都会有自己的迁移？您将实际测试什么以确保该领域是他们的？

我真的很想弄清楚从哪里开始以及如何细化。我开始着手，只是冻结，因为我不知道如何测试每一件小事。

我见过的大多数示例都使用验证作为示例。我知道在那之前写了很多代码，我只是不知道如何测试最基本的东西，比如“应该有一个名字字段”。

任何帮助深表感谢。

谢谢！

我们的许多系统测试都是以 BDD 风格编写的，我们充分利用继承的行为来最大限度地减少重复，例如，这可能是购买测试的基本层次结构。

在这种情况下，BehavesLikeSuccessfulPurchase定义的常见行为（如帐户对帐单）应该有一个借记条目，并且BehavesLikePurchaseWithValidCreditCard该类定义了使用有效信用卡购买任何类型产品的测试工作流程，因此测试是简单地提供具体产品实例的小型派生类，例如

但是，根据具体的产品类型，我们还需要进行一些额外的检查，例如，每当成功购买视频时，我们都希望检查它是否已添加到用户的视频库中。理想情况下，这可以由另一个类定义并混合使用，使用假设的语法：

但是当然 C# 不支持多重继承或混合，所以我们最终编写了一堆样板方法，将调用转发到其他行为，每次行为改变时都需要改变。

我们真正需要的是一个框架，它有自己的机制来支持测试中的多种行为，只需提供应该观察的其他行为的类型。我一直在查看 xUnit 和规范示例，看起来有可能提出一些可以解决问题的扩展，但是是否已经存在任何东西？

我是 BDD 世界的新手，我一直在努力尝试从自上而下的方法中获得最佳效果，许多人强烈推荐。考虑到这一点，您会推荐什么作为指定控制器行为的良好起点？我的意思是，例如，在 CRUD 控制器场景中需要测试什么？

问候，

亚历克斯

有人可以使用一个简单的用户故事来阐明 Cucumber 将用于什么以及 RSpec 将用于什么的完整部分吗？前几天我购买了 RSpec 书，并且一直在阅读它。作者有时似乎很模糊。

如果用户故事是这样的，我在想什么（请原谅语法不正确，这只是为了让您明白这一点）：

当用户输入无效的电话号码时，他们会收到一条消息，提示“无效的电话号码”

如果我写出 Cucumber 的所有代码来检查这一点，然后编写 rspec 的东西，我基本上是在复制我的测试。是否有一个场景可以解释黄瓜测试与 rspec 测试有何不同？

我觉得你会一直在两个级别上重复测试。

如果对此没有明确的答案，我将开始认为 Cucumber 人只是不想踩到 RSpec 人的脚趾。

请帮忙。我感觉我的头快要爆炸了。

谢谢！

PHP 有点残缺，因为它没有返回类型（还）。当 X 已经存在时，我需要我的代码抛出异常。我可以在一个场景中编写这个，但我无法从场景转到我的类应该实现的接口。

实际上，我猜这个问题在 TDD 中是相同的。我似乎可以通过我的“测试”而不是通过我的界面来判断。然而，我的接口定义了哪些组件可以交互，它们应该承担哪些责任。

PHP 中的问题更大，因为它没有返回类型，但它也存在于其他语言中，因为没有约定在 x 是这种情况时应该抛出异常。

我怎样才能最好地处理这个问题？

我已经看到在我看来是 BDD 的两种方法。差异取决于“何时”的位置：

在方法 1 中，when 是规范的一部分：

在纯粹的“当时给定”的术语中，这是：

“给定一个空栈，当它被压入时，它就不再是空的了。”

所以“何时”是规范方法的一部分：

在方法 2 中，何时在类级别定义。也就是说，通常在设置中调用when。

有首选方法吗？就行为的纯测试而言，第二种选择对我来说似乎更可取，因为测试夹具的重点是行为。

但是，为了便于测试，我倾向于第一种方法。我在测试中发现的大部分痛苦是设置。也就是说，我必须得到一个处于特定状态的 SUT。一旦处于该状态，通常只有一行代码可以实际调用它的某些行为。因此，每个类（即每个设置上下文）具有多个行为会利用类的一次性设置。

所以，我正在寻找想法。一种方法优于另一种方法吗？