假设我有三种方法，它们都非常相似，但输入类型不同：
void printLargestNumber(int a, int b) { ... }
void printLargestNumber(double a, double b) { ... }
void printLargestNumber(String numberAsString, String numberAsString) { ... }
这三个都使用相同的底层逻辑。例如：也许double版本是唯一比较数字的版本，而另外两个只是将它们的输入转换为double.
我们可以想象一些不同的单元测试：第一个输入更大，第二个更大，两个输入都是负数，等等。
我的问题
如果所有三种方法都有完整的测试集（黑盒，因为我们不假设核心实现是相同的）
或者
是否应该只对double版本进行大量测试而对其他两个版本进行轻微测试以验证参数转换（白盒测试，因为我们知道它们共享相同的实现并且已经在测试中进行了double测试）？
如果所有这些方法都是公开的，即可以被外界调用，我肯定会用一整套测试来测试它们。一个很好的理由是白盒测试比黑盒测试更脆弱。如果实施发生变化，其中一些方法的公共合同可能会发生变化。
这取决于。
您认为实施可能会改变吗？如果是这样，那么进行黑盒测试。
如果您可以保证实现不会改变，请使用白盒。但是，您能够保证这一点的机会不是 100%。
您可以妥协并进行一些黑盒测试，尤其是在边界条件附近。但是，编写测试应该很容易——所以从这个角度来看，没有理由不进行完整的黑盒测试。唯一的限制因素是运行测试所需的时间。
也许您应该调查并行运行测试的可能性。
有一组测试明确地使用公共接口。我会将这些视为黑盒测试。
还有第二组测试可以看作是查看实现的极端情况。这是白盒测试，肯定在单元测试中占有一席之地。如果没有一些白盒实现知识，您将无法知道有趣的路径。我会特别注意字符串的情况，因为接口允许字符串可能无法干净地转换为双精度，这会推动精度的边界等。
我会在整数情况下偷工减料吗？我知道我在双重情况下推动了道路，可能不应该但可能会受到时间压力。