Unit testing 将TDD用于库/API代码和BDD用作集成测试是否有意义？

我是BDD的新手，我想了解它在开发周期中的作用。在TDD方法中，我们通常会为库或API编写单元测试，我们会模拟对象，这很好，因为它甚至可以驱动我们的设计。这些测试将在实际代码之前编写，这很好

我理解BDD更多的是关于规范/场景测试，我可以看到它非常适合根据实际代码测试业务需求。但是编写这些测试的最佳实践是什么？我们是否仍在编写单独的测试（如TDD）来模拟依赖关系，并为可能出错的每一件事编写单元测试？然后写我们的bdd测试？我们是否先编写bdd测试？我们是否只针对单个组件编写bdd测试

我使用.NET，通常编写asp.NETMVC应用程序，但这更多的是一个理论问题，与底层编程语言无关

---

非常感谢。

我不知道正确的方法，但这是我的经验。在分析规范文档之后，我尝试提取尽可能多的不同“故事”，并使用BDD故事文件描述它们。正如您已经知道的，每个句子都应该以给定的三个关键字中的任意一个开始，时间和时间

在将整个规范翻译成BDD测试故事之后，我编写了一个实现步骤的类，即执行故事中使用的每一个句子

下一步是开始编写一个实现，该实现将由通过设置初始状态（给定）、状态转换（何时）和检查应用程序的目标状态（然后）来执行脚本语句的方法调用

每当我需要实现一个实际的类方法时，我都会使用TDD单独进行彻底的测试

---

当然，为了运行测试，可能会临时模拟尚未实现的代码部分。

您可以将其与TDD、单元测试或其他类似方式使用。区别在于测试“商业行为”。specflow和Features是一个选项，单元测试语法如下所示

[Given(@"a user exists with username ""(.*)"" and password ""(.*)""")]
public void GivenAUserExistsWithUsernameAdminAndPasswordPassword(string userName, string password) {

}

[Then(@"that user should be able to login using ""(.*)"" and ""(.*)""")]
public void ThenThatUserShouldBeAbleToLoginUsingAdminAndPassword(string userName, string password) {
        Assert.IsTrue(_authService.IsValidLogin(userName, password));
    }

---

BDD是一组围绕描述和构建系统行为模型（以及更高级别的项目愿景）的模式，它可以帮助我们就不同粒度级别的行为进行对话

我们使用诸如“给定上下文，当事件发生时，结果应该发生”之类的对话模式，并鼓励提出诸如“应该吗？总是吗？我们还缺少其他上下文吗？”

我们可以在单元级、场景级甚至分析空间中这样做

我倾向于从最高层次的内部工作。它描述了从项目愿景到单元测试的整个过程

我编写的第一段代码是场景。没有任何BDD框架，只是简单的老NUnit，展示了如何使用域语言使这些英语可读，等等

然后我从用户界面开始。这可以是GUI、网页或其他系统使用我的系统的界面。完成后，我可以得到用户是否喜欢它的反馈。我经常硬编码数据等，只是为了得到反馈

一旦我大致了解了GUI的外观，我就可以开始创建它背后的行为了。我通常从控制器的行为开始。我将写一些班级级的例子来描述班级的行为和责任。我使用mock代替我还没有编写的协作类。这相当于TDD，但我并没有编写测试来固定代码，这样就不会有人破坏它，而是编写示例来说明如何使用我的代码，展示代码的行为方式以及它的价值，以便安全地更改代码。我也用Given/When/Then来表示这个！但我倾向于使用更专业的语言，不担心它的英文可读性。通常我的“给定的/何时的/然后”只是在评论中。从与场景相同的代码库中，您可以看到不同之处

---

希望这有帮助，祝BDD好运

如果我理解正确，您首先要构建一个原型，为反馈演示它，然后修改它？这可能适用于小型项目，但对于大型和复杂的项目来说是一种糟糕的方式。在这些例子中，原型被扔掉了。另外，如果GUI很复杂，您应该使用“presenter first”或MVC模式，“make one to Wave”模式在瀑布中最为相关。如果代码被创建为易于更改，您就不需要这样做，BDD起源于敏捷实践（特别是XP和TDD）。它不是一个原型——它是真实的代码，我们已经在许多企业项目中这样做了。另外，请阅读我说的“我通常从控制器的行为开始”这句话，这应该告诉你我在做MVC。Lunivore我可以得到一些关于如何测试没有用户界面、数据库连接等的库项目（比如数学库）的评论。只是简单的旧库。我的意思是，这个例子听起来非常适合TDD-不是吗？ThanksA库通常仍然有一个类或一组类作为主“用户界面”，即使它是另一个使用它们的系统。我会从“用户界面”中编写场景——例如，求解二次方程——然后为每个类编写单元级示例（测试，在TDD中），这有助于添加到场景中——例如，平方根、除法等。BDD不仅仅是场景级的；它也适用于单元级别——参见我的课堂行为示例。顺便说一句，我的例子也是一个库——我已经通过提供一个使用它的代码库展示了如何使用它，这是另一种方式。BDD也不是真正专注于测试——它专注于对话和发现。你会得到一些自动化的场景和例子作为一个不错的副产品，这是非常幸运的