我在这里讨论了单元测试的价值：
如果我可以使用集成测试，为什么我要麻烦单元测试呢？
但我想我可以从中推断出，单元测试对于谨慎的逻辑方法是好的，但当数据被操纵时，你需要回到集成测试上。
我遇到的问题是，在现实世界中的LOB应用程序中，它们99%的工作都是处理数据，这是否意味着只有1%的典型应用程序适合进行单元测试？
集成测试只是测试接口是否返回预期结果。单元测试是非常具体和非常小的测试，以确认内部构件是否工作。它们有助于暴露代码中集成测试很难发现的黑暗区域。如果您从未被允许更改或重用正在测试的组件，那么集成测试是非常棒的。
单元测试可以让您对目前可能没有使用的代码功能充满信心，或者可能会出现导致它们行为不端或失败的奇怪情况。这有点像是对汽车的各个档位进行压力测试，而不是滥用整个汽车使其失效。
关于数据操作，如果您在对流程进行单元测试时遇到困难，那么它应该指出您还没有很好地将其模块化。
当涉及数据时，我仍然会使用单元测试。例如，当我在web应用程序中测试响应处理程序时，我不想为了测试处理程序而触发实际的ajax请求。相反，我将一些示例json放在一个字符串中，然后将其传递给我的处理程序。
如果我正在编写一个从文件中读取数据的应用程序，那么我的数据处理方法将与实际反序列化文件的代码完全分离。因此，在这种情况下，我可以再次获得一些真实世界的数据，并将其传递给测试中的数据处理方法。
您将看到，使用单元测试也会通知您的代码的设计。在这些示例中，处理数据的方法/类与我获取数据的方式完全分离（即解耦）。
需要注意的是，我可能也会在其中加入一些集成/功能测试，但我完全不同意单元测试只在1%的时间内适用的观点。