我在这里讨论了单元测试的价值：
Why should I bother with unit testing if I can just use integration tests?
但我认为我可以从中推断出单元测试对于谨慎的逻辑方法是有利的，但是当数据被操纵时，你需要回到集成测试。
我遇到的问题是在现实世界的LOB应用程序中，他们所做的99％都是操纵数据，这是否意味着只有1％的典型应用程序适合单元测试？
答案 0 :(得分：2)
集成测试只是测试界面是否返回预期的内容。单元测试是非常具体的，非常小的测试，以确认内部是否正常工作。它们有助于暴露代码的黑暗区域，这些区域对于集成测试很难找到。如果您永远不允许更改或重用正在测试的组件，那么集成测试非常有用。
单元测试使您对现在可能未使用的代码功能有信心，或者可能会遇到导致它们行为不端或失败的奇怪情况。它有点像压力测试汽车的各个齿轮，而不是滥用整辆汽车让它们失败。
关于数据操作，如果你在这个过程中难以进行单元测试，那么它应该指向你，你还没有很好地模块化它。
答案 1 :(得分：1)
当涉及数据时，我仍然会使用单元测试。例如，当我在webapp中测试我的响应处理程序时，我不想激发实际的ajax请求来测试我的处理程序。相反，我将一些示例json放在一个字符串中，然后将其传递给我的处理程序。
如果我正在编写一个从文件中读取数据的应用程序，那么我的数据处理方法将与实际反序列化文件的代码完全分开。所以在这种情况下，我会再一些真实的数据，并将其传递给测试中的数据处理方法。
您将看到使用单元测试还会通知代码的设计。在这些示例中，使用数据执行操作的方法/类与我获取数据的方式完全分离（即解耦）。
作为一个注释，我可能会在那里进行一些集成/功能测试，但是我完全不同意单元测试只适用于1％的时间。