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