单元测试应该是黑盒测试还是白盒测试？

说我有三个方法，都非常相似，但不同的输入类型：单元测试应该是黑盒测试还是白盒测试？

void printLargestNumber(int a, int b) { ... } 
void printLargestNumber(double a, double b) { ... } 
void printLargestNumber(String numberAsString, String numberAsString) { ... }

三者都使用相同的基本逻辑。例如：也许double版本是唯一一个比较数字的版本，另外两个版本只是将其输入转换为double。

我们可以想象几个不同的单元测试：第一个输入较大，二是大，两个输入为负，等

我的问题

如果所有这三种方法有全套测试（黑盒子，因为我们不承担核心实现是一样的）

或

应该只在double版本会被严重测试，另外两个测试会轻微验证参数转换（白盒测试，因为我们知道它们共享相同的实现，并且已经在double测试中进行了测试）？

来源

2010-12-01 Brad Cupit

Hrm ...这可能是一个愚蠢的http://stackoverflow.com/questions/203075/should-i-use-glass-box-testing-when-it-leads-to-fewer-tests – 2010-12-01 23:05:58

如果所有这些方法都是公开的，也就是说可以被外界调用，我肯定会用全套测试来测试它们。一个很好的理由是，白盒测试比黑盒测试更脆弱;如果实施变更，公共合同可能会因某些方法而发生变化。

来源

2010-12-01 22:07:55 Kaitsu

这取决于。

您是否认为实施可能会改变？如果是这样，那就去黑盒测试吧。

如果您可以保证实施不会改变白盒子。但是，您能够保证这一点的几率不是100％。

您可能会妥协并进行一些黑盒测试，特别是在边界条件附近。但是，编写测试应该很容易 - 所以从这个角度来看，没有任何理由对而不是进行全黑盒测试。唯一的限制因素是运行测试所需的时间。

也许你应该研究并行运行测试的可能性。

来源

2010-12-01 22:11:16 ChrisF

+ 1为“写测试应该很容易”。确实，它们都是非常相似和易于编写的，如果实现发生变化（这是测试的目的！），这将会有所帮助。感谢你的回答！ – 2010-12-01 23:01:44

你不能保证实现不会改变。不是50％，不是20％，不是1％。你不能。一切都可能在某个时候改变。如果你只测试了代码的一部分，“因为我知道这实际上是这个代码的别名”，那么当它发生变化时（如果你没有马上意识到）就停止测试代码的一部分。不好。总是假设一切都可以，并且它的大部分*会在某个时刻改变。相应地测试。 – 2013-02-24 23:19:26

有一组测试明确行使公共接口。我会将这些视为黑盒测试。

还有第二组测试可以看作是实施的角落案例。这是白盒测试，肯定在单元测试中占有一席之地。没有白盒实施知识，你无法知道有趣的路径。我会特别注意字符串的情况下，因为接口允许字符串，可能不会干净地转换为双打，推动精度等边界

我会削减整数情况下的几个角落？我知道我在双重案件中推动了道路，可能在时间压力下不会好起来。

来源

2010-12-01 22:15:47 djna

单元测试应该是黑盒测试还是白盒测试？

回答

相关问题