Unit testing 单元测试逻辑、集成测试数据

我在这里讨论了单元测试的价值：

但是我想我可以从中推断出，单元测试对于谨慎的逻辑方法是好的，但是当数据被操纵时，你需要回到集成测试上来

---

我遇到的问题是在现实世界的LOB应用程序中，它们99%的工作是操作数据，所以这是否意味着只有1%的典型应用程序适合进行单元测试？

集成测试只是测试接口是否返回了预期的结果。单元测试是非常具体和非常小的测试，以确认内部工作正常。它们有助于暴露集成测试很难找到的代码的黑暗区域。如果不允许您更改或重用正在测试的组件，那么集成测试是非常好的

单元测试可以让您对代码的功能有信心，因为这些功能可能现在还没有使用，或者可能会受到一些奇怪的情况的影响，从而导致它们行为不当或失败。这有点像是对一辆汽车的各个档位进行压力测试，而不是滥用整个汽车使其失效

---

关于数据操作，如果您很难对流程进行单元测试，那么应该指出您没有很好地将其模块化。

当涉及数据时，我仍然会使用单元测试。例如，当我在一个webapp中测试我的响应处理程序时，我不想为了测试我的处理程序而触发一个实际的ajax请求。相反，我将一些示例json放在一个字符串中，然后将其传递给我的处理程序

如果我正在编写一个从文件读取数据的应用程序，那么我的数据处理方法将与实际反序列化文件的代码完全分离。因此，在这种情况下，我可以再次使用一些真实世界的数据，并将其传递给测试中的数据处理方法

您将看到，使用单元测试也会影响代码的设计。在这些示例中，处理数据的方法/类与我获取数据的方式完全分离（即解耦）

---

值得注意的是，我可能会在其中加入一些集成/功能测试，以便更好地衡量，但我完全不同意单元测试只在1%的时间内适用的概念。

我想我当时说的是，我正在测试一个单层的数据访问方法，但我让它从“样本”中提取出来将已知数据作为测试源的数据库。这节省了为每个单元测试制作数据的时间。所以我认为这是一个混合测试？