在项目生命周期的哪一点开始编写测试？

Question

我没有在领域，所以我没有任何专业经验，从项目跟随TDD设计。我正在尝试采用这种模式，但我对何时开始实际编写测试感到困惑。在我的例子中，一个个人博客应用程序。我从完全从头开始使用ASP.NET 5，MVC 6，我构建了主要的功能，比如显示主页，允许使用身份登录，允许发布博客文章，以及通过MVC控制器和API检索这些博客文章。

所有这些都是使用Repository模式和MVVM完成的。

在这个过程中，我应该在什么时候真正开始测试？

我是否测试存储库是否做了它应该做的事情？这闻起来怪怪的，因为储存库是可以注射的。

我是否测试ViewModel是否具有某些属性？

或者简单地从测试一个有效的ViewModel是否允许创建一个新的BlogPost开始，而无效的不允许创建一个新的BlogPost是可以接受的吗？

Answer 1

TDD主要围绕单元测试，这个答案将涵盖这一点。

你为什么要申请？您是让他们看到C#运行良好，还是让他们解决客户端提出的问题(请注意，有时客户端可能也是您)？

除非您是微软公司的.NET开发人员，并且实际上负责维护C#语言，否则这几乎总是第二种情况。你试图解决一个问题，一个问题，它有一些规则。

提供给您的规则是您的业务逻辑，您的域。一旦您开始在域上工作，这是您应该开始编写测试的最新时间。

最新的？是。从高级PHP开发人员的职位上讲，尽管PHP允许您完成编译语言无法完成的许多事情(例如从方法中返回两个完全不同的对象)，但这会导致错误的代码。因此，在许多情况下，最好只是编写数据库层，而不是依赖现有的静态方法解决方案等等。如果您确实构建了这个层，您也可以考虑为此编写测试，以确保您所写的内容有效。

一般来说，开始编写单元测试永远不会太早，但总有一天会变得太晚，变得不必要。例如单元测试您的控制器。我见过人们这样做，这不是单元测试应该做的。控制器是一个过程，包含服务工厂、实例化它们、处理域对象，它们不是单元。如果要测试控制器，请使用集成测试套件。

，那么应该总是测试什么？

您希望对您的域、业务逻辑进行单元测试。如果您有此功能，并且您的业务规则确实只存在于此，那么您实际上不需要担心应用程序的其余部分，因为它只应该对数据执行基本的CRUD操作，这是有效的(感谢测试和良好的域模型)。

从生命周期角度看

TDD

TDD意味着您首先编写测试，然后编写代码。当你在做一个项目的时候，你经历了几个阶段。

1. 选择正确的技术--你不知道你要选择哪种编程语言，因此不能简单地编写测试。
2. 选择您的体系结构模型-您选择了编程语言，但不知道您的项目将如何结构。会是模块，服务，MVC吗？在您的例子中，它很可能是MVVM模式。你的整个架构被认为是一个单元吗？我不这样认为。您不需要测试应用程序的架构。
3. 设计您的域层--这是您将用户功能和非功能需求以及来自客户端的规则一起进行实现的部分。在这个阶段之前，您应该编写测试，然后提供实现以使它们通过。
4. (可选)设计使用域模型的服务--您可以创建将更多域操作合并到一个过程中的服务，就像facade一样。您可以在设计这些服务之前编写测试，但这是一个可选的任务。

如前所述，为了确保应用程序(连接部分)按预期工作，您应该使用集成测试而不是单元测试。

Answer 2

在这个过程中，我应该在什么时候真正开始测试？

嗯，你专门问了关于tdd的问题，所以只有一个正确的答案:在你做任何其他事情之前。

测试驱动的开发和设计被称为测试驱动，因为测试驱动开发和设计。测试告诉您何时开始编写代码。他们告诉你该写什么。他们告诉你怎么写。他们会告诉你下一步该写什么。非常重要的是，他们告诉你什么时候完成写作。

为了做到这一点，他们必须存在。在你做任何其他事情之前，你做的第一件事就是写一个测试。

注意:我不是说这是唯一的方法，但你问了关于TDD，如果你不遵循这一点，那就不是TDD。

一般的TDD周期看起来如下(实际上是4个循环，嵌套了3个级别)：

1. 选择一个用户故事(您如何做到这一点超出了TDD的范围，例如，您可以使用Scrum或XP来确定下一步要选择哪个故事)。
2. 编写最简单的验收测试，这可能会导致用户故事的验收标准失败。
3. 做你的验收测试。
4. 注意验收测试(只看那个测试！)你刚刚写的是失败。
5. 验证它是否出于正确的原因而失败。
6. 只要测试失败，重复：
   1. 选择一个独立的行为单位
   2. 编写最简单的单元测试，对于该行为单元可能失败。
   3. 运行单元测试。
   4. 看单元测试(只看那个测试！)你刚刚写的是失败。
   5. 验证它是否出于正确的原因而失败。
   6. 只要测试失败，重复：
      1. 编写可能更改错误消息的最简单代码。

1. As soon as the test passes, as long as there is something to improve, repeat:  
    1. Refactor Mercilessly

Keith创造了一个他称之为TDD好像你是认真的的练习。它由一组规则(基于鲍勃·马丁叔叔的三条TDD规则，但严格得多)组成，您必须严格遵守这些规则，这些规则旨在引导您更严格地应用TDD。它最好与配对编程(以便您的一对可以确保您没有违反规则)和教练。

您可以在以下两个问题中更多地了解到这一点：

• 如何进行测试驱动开发
• 基本TDD中的廉价实现

Answer 3

通常，在编写方法的声明之前，您不能为方法编写测试，因为测试不会编译。在至少编写方法的空定义之前，您不能运行测试，因为测试不会链接。所以最好的顺序是：

(a)规划你想做的事情。(b)填写该方法的声明。(c)编写单元测试。(d)填写该方法的空定义。(e)运行单元测试，确保报告故障。(f)实施这一方法。(g)再次运行单元测试，以确保它们成功。(h)随着您对问题的新洞察，改进单元测试，并根据需要改进方法。