13.3.2 如何为方法设计完备的测试用例，尤其是当方法的副作用很复杂、环境难以模拟的时候？

[GreyZeng]

一个软件有很多可能的输入和环境参数，我们没有能力穷举所有的可能，也没有必要。我们可以运用不同的设计测试用例的方法，有效地生成测试用例。

我在做软件测试的时候，遇到的最困难的问题是如何处理有副作用的方法。这里的“有副作用”代表该方法与外界有交互，比如从控制台读入一行字符串，又或者是连接一个数据库。如果我想对这些方法进行测试，就需要模拟出一整个环境，这在紧张的快速开发中是难以做到的。因此，在设计单元测试用例时，我往往会选择跳过这些有副作用的方法，只测试那些纯函数。但软件的Bug往往是在这些与系统有交互的地方产生的。所以我想知道，该如何为这些方法设计完备的测试用例，尤其是当方法的副作用很复杂、环境难以模拟的时候？

原文地址

[GreyZeng]

Ruby on Rails这个框架教会了我一个道理：没有什么是一个测试文件解决不了的，如果有，那就上一个集成测试。之前我过于拘泥在单元测试的泥潭里无法自拔了，后来在实践的过程中我发现，单元测试只是测试的一种手段，在实际的软件测试中，集成测试才是更好用、性价比更高的测试方法。集成测试把软件当成一个黑箱，关心软件的运行状态是否达到预期，其测试粒度相比单元测试要大上不少，可以将许多方法及其副作用包络起来，从接近用户的角度去做测试。因此，设计测试用例的时候，遇到那些不好做单元测试的方法，索性就把它们放在集成测试中，一次性全部测完。
原文地址