问TDD和3层架构

EN

编写测试是为了证明满足了功能和业务需求。因此，我针对正在使用的类的公共接口进行编码。公共接口向下钻取到内部和私有类。如果在较低级别抛出异常，或者函数返回错误的数据，我将在针对业务规则的测试中捕获该异常。

例如，如果Employee是一个业务类，并且它调用了EmployeeSerializer.GetAll()，那么我只需要测试Employee.GetAll。如果EmployeeSerializer()没有返回正确的数据，我会知道的。如果EmployeeSerializer抛出一个意外的异常，我会知道的。如果EmployeeSerializer没有抛出正确的异常，我会知道的。

不要通过编写测试代码来验证实现细节。对它们进行编码以测试业务规则。这意味着您要测试业务对象。为了促进这项工作，我将我的数据访问对象标记为内部对象，因此我不能在预期使用它们的业务上下文之外对它们进行测试。

但这就是我，我相信其他人也会有不同的看法。

附录:尽可能将业务规则排除在存储过程之外。此外，使用Setup和TearDown设置已知测试。请记住，测试将测试整个业务规则。您可以自由地执行尽可能多的工作来设置测试，只要测试在隔离状态下执行，并且在测试完成时可以将环境恢复到其原始状态。因此，如果您想插入数据，请确保您有一个执行此操作的业务类方法。更新、删除和选择也是如此。

首先，我要说的是，多读一点关于Mocks的知识(你模拟角色...而不是数据/对象)。

W.r.t.对于你的例子，我会有

1. 单元针对表示类/视图模型(您的UI层)进行测试。在这里，我将模拟业务层/角色。例如，当我对域类(业务层)进行X
2. 单元测试时，验证表示类在服务上调用正确的方法。在这里，我模拟数据访问层。例如，当我做X
3. 集成测试时，验证GetCustomer()是否被调用，以测试MyRepository.GetCustomer()是否正确地从“真实”测试数据库中提取数据。因此，理想情况下，应该在此处捕获并标记StoredProc中的错误。

除此之外，在合同双方对另一方应该如何表现有不同想法的情况下，可能存在错误。为此，您需要编写一些端到端的验收测试，以测试连接在一起的所有组件(就像它们在生产中一样)。

TDD可以用于上述所有功能。