问题标签 [testdrivendesign]

我们在构建服务器中使用代码分析，严格限制如果代码分析规则中断，我们不能提交代码。CA1822 已启用，因此我们有很多很多静态功能。现在我们想通过模拟和依赖注入来强制进行单元测试。但是对于我们的许多静态函数来说，模拟一些静态函数并不容易。特别是当静态函数调用静态函数时。我正在考虑禁用 CA1822 以减少静态功能，因为我在问自己：CA1822 对于使用模拟固件和代码注入的开发来说已经过时了吗？我读过许多其他问题，表现不是问题。那么如何使函数静态化呢？在我看来，CA1822 导致了糟糕的设计。我错了吗？

我对测试驱动开发比较陌生，我只是想知道我应该从哪里开始？我了解如何进行测试。我的意思是我应该先测试什么？对此有最佳做法吗？我应该先测试模型吗？控制器？我是否应该首先编写集成测试，然后从那里构建所有内容以使其通过？

对此有何看法？

它们是同一种东西但名称不同吗？

两者中的“测试”这个词让我觉得它们很相似。

我正在从头开始新项目，我希望有很高的单元测试覆盖率。假设我们有 ClassA、ClassB 和 ClassC 以及 ClassATest、ClassBTest、ClassCTest。在 ClassB 和 ClassC 的 ClassATest 真实对象中使用是一种好习惯，以便所有类都在 ClassATest 中进行测试，还是我应该 ClassATest 使用 ClassB 和 ClassC 的模拟并且只创建 ClassA 的真实实例？我在实例化 ClassB 和 ClassC 时没有任何麻烦，而且我看不出有任何理由在这里使用模拟。

我必须编写一个java程序，并证明我在编写程序时使用了TDD。我需要找到一些方法来证明测试驱动开发的使用，这意味着以某种方式记录一些测试的失败，然后记录一些代码的编写，然后记录通过的测试，等等。欢迎任何帮助。此外，任何与 java 相关的 TDD 文档资源都会有所帮助！谢谢！

根据维基百科，以下是 TDD 中的步骤：

第一步：编写单元测试

第二步：运行单元测试

第三步：编写模块代码

第 4 步：再次运行所有测试

第五步：清理代码

第6步：重复步骤

问题1：在TDD中我们主要写单元测试。集成测试和系统测试在上述步骤中的位置是什么？

考虑以下示例：

假设我们有一个必须开发的功能。然后根据 TDD，我们将在短期迭代中开发此功能。假设我们将此功能分为 2 个模块 - 模块 1 和模块 2。我正在编写迭代步骤，以根据上述给定步骤在 TDD 中开发这些模块。（问题2）请在以下步骤中纠正我的错误：

**迭代 1：**

第 1 步：我们为模块 1 编写单元测试。

第 2 步：为模块 1 运行此单元测试（此测试将失败）

第 3 步：为模块 1 开发代码。

第 4 步：再次为模块 1 运行单元测试（此测试将通过）

**迭代 2：**

第 1 步：为模块 2 编写单元测试

第 2 步：为模块 2 运行单元测试

第 3 步：为模块 2 编写代码

第 4 步：运行模块 1 的单元测试和模块 2 的单元测试。（问题 3：在此步骤中，为什么我们在模块 2 处于测试状态时运行模块 1 的单元测试？如果你说这样做是因为要测试模块 2 是否不会破坏模块 1 的功能，那么我的问题是，这里我们只测试模块 2。它还没有与模块 1 集成，那么它将如何破坏模块 1？）

**第 3 次迭代：**

第 1 步：创建集成测试（我在这里吗？）

第 2 步：运行集成测试（它们将失败，因为模块 1 和模块 2 尚未集成）

第 3 步：集成模块 1 和模块 2

第 4 步：运行所有测试（模块 1、模块 2 和集成测试的单元测试）

（问题 4：为什么在这一步我们要运行模块 1 和 2 的单元测试？）

迭代 4（当所有模块都集成时）：

步骤 1：创建系统测试

第 2 步：运行系统测试（它们会失败）

第3步：（问题5：）我应该在这里写什么代码，因为系统测试我们不写任何代码，根据TDD原则，我们先写测试，然后再写开发代码，那么我们在这里写什么代码？

我实际上正在研究 TDD 等等，我通过例子学习。

实际上我正在构建一个小（非常非常少）ORM 来向我介绍真正的单元测试，带有存根和模拟。

我以这种方式运行，我进行了测试并做了一些小实现（getAll 方法）（失败 -> 使测试通过 -> 重构）

实际上，这是我的代码：

MongoDB适配器

mysql适配器

工厂适配器类

相关的单元测试：

测试MongoAdapter

以此类推其他两个。在这种情况下，我的问题不在于语法方式。

问题

实际上，我想在相关适配器中使用来自 MYSQL 和 MONGODB 的 DB 驱动程序。实际上，我知道我应该做什么实现：在 FactoryAdapter.get 中创建它的实例时，将驱动程序传递到 Adapter 的构造方法中

我的问题是，从那时起，我不知道在实现我的代码之前我应该​​编写哪个测试（应该失败）。

我们目前面临的情况是模型实体和数据库逻辑紧密交织在一起，这使得单元测试变得不可能。所以，我决定设计一个存储库模式。我们通过 Com 交互 Root-Children[每个孩子都是另一个 Root] 看到的存储模型的基本结构。这是一个树形结构。了解了这一点，我们设计的存储库是用于根上的 CRUD 操作的 RootRepository，而 RootRepository 内部的 ChildRepository 用于子级的 CRUD 操作。我们决定 Create 仅用于创建实体但不持久化它，但更新将仅在数据库中未找到任何实体键时插入或在找到时更新。Read 将按键获取实体。因此，在与存储库 API 交互时，我们决定首先使用密钥获取实体，如果它为空，则调用创建基本实体（存储库使用工厂），如果需要，可以对其进行更新，并使用更新将其持久化回数据库。因为它是一个指向另一个实体的 Value 对象，所以它本身不能被持久化。要持久化子对象，我们必须先持久化子引用实体，然后再请求根存储库以创建子对象，并且可以将其添加到父子集合中，并调用父持久性，这样子对象将与父对象一起持久化。

所以，我想知道我们所遵循的方法和设计模式真的符合标准。据我们所知，这是我们获得单元测试支持和使用最少数据模拟进行测试的唯一方法。我在网上四处寻找构建存储库的想法，但没有任何帮助。我在这里的大部分问题都将在我们的单元测试中得到解决，但我想知道是否已经存在任何设计模式。在这个早期阶段，很容易迁移到任何标准框架（如果存在），我希望我能从你们那里得到任何指导。

如何从领域层的 TDD 开始，我的意思是如何测试领域模型？

应该测试什么？聚合体或每个实体？

测试洋葱架构领域层有哪些好的实践和策略？