我有一个REST Web服务接口，可以调用服务层，该服务层可以协调实体层中各种对象的创建，删除等。这些实体层对象最终映射到数据库记录。我有一些单元测试（在nunit中，它是一个c＃应用程序），它通过发送http请求来测试这个接口。
考虑我测试创建一个实体层对象的Web服务请求。我显然想通过检查它返回给我的http状态以及响应正文中的一些数据来验证Web服务是否认为请求已被正确处理。我还想独立验证是否已创建正确的数据库记录。我有几种方法（我能想到）来做到这一点：
最简单的方法是使用实体层中现有的“reader”类来读取和验证数据库条目。这很容易，因为它们为它们处理的实体合并了验证和一致性逻辑，并且使用它们很简单。不过，我对此感到不安，因为我将使用我正在测试的代码测试的一部分。这似乎违反了一些关注点分离的原则，并且还引入了实体层错误导致对象创建失败但在单元测试中看起来成功的可能性。
或者，测试代码可以直接进入数据库并自行进行检查。但后来我在测试中嵌入了有关对象存储和一致性规则的细节 - 如果这些细节发生变化，这会使测试变得脆弱，并且还有效地意味着在单元测试中重新实现我已经在实体中编写的代码层
我想知道人们如何看待与这些（可能还有其他）选项有关的权衡，以及最佳实践（如果有的话）是什么？我不确定是否有正确或错误的答案，但我已经好奇了一段时间并对其他意见感兴趣。
修改
为了澄清，我为服务层和实体层保存了单独的测试套件。我所表达的关注 - 在测试中使用经过测试的代码 - 也适用于这些测试。
答案 0 :(得分：4)
我们看到两种不同的测试，即服务方法的测试和webclient的测试。
为了测试服务方法（如读者），如果读者输出以所需方式匹配测试数据，您可能需要创建具有预定义值（测试数据）的数据库，调用读取器并进行测试。 / p>
一旦您测试了服务方法，您就可以转到下一个测试级别并再次使用相同的测试数据测试Web客户端，但现在测试Web客户端上显示的数据是否与所需的测试数据相匹配。在这个测试级别，您可以“信任”读者（因为他们之前已经过测试）。
如果您将“单元测试”和“集成测试”分开，可能会感觉更舒服。对于单元测试，请验证编译单元是否按要求工作。这可能正在测试读者：您使用已定义的数据填充数据库，调用findAll()（或其他内容），并断言测试数据和测试数据仅在结果中。
另一个测试是集成测试 - 在那里验证，服务层和实体层按预期一起工作。与测试Web客户端相同：验证客户端/服务层是否按要求工作。
对于集成测试，我认为没有任何理由不使用（测试）服务层方法。