在我的上一个项目中,我们的单元测试几乎达到了100%cc,因此我们几乎没有任何错误.但是,由于单元测试必须是白盒(你必须模拟内部函数来获得你想要的结果,所以你的测试需要知道你的代码的内部结构)任何时候我们改变函数的实现,我们不得不也改变测试.请注意,我们没有更改函数的逻辑,只是实现.这非常耗时,感觉好像我们的工作方式不对.由于我们使用了所有适当的OOP准则(特别是封装),每次我们更改实现时,我们都不必更改其余的代码,但必须更改单元测试.感觉好像我们正在为测试服务,而不是为我们服务.
为了防止这种情况,我们中的一些人认为单元测试应该是黑盒测试.如果我们创建整个Domain的一个大模拟并为一个地方的每个类中的每个函数创建一个存根,并在每个单元测试中使用它,那么这是可能的.当然,如果特定的测试需要调用特定的内部函数(就像确保我们写入DB一样),我们可以覆盖我们的存根.
因此,每次我们更改函数的实现(比如添加或替换对帮助函数的调用)时,我们只需要更改我们的主要大模拟.即使我们确实需要改变一些单元测试,它仍然会比以前少得多.
其他人认为单元测试必须是White Box,因为不仅要确保你的应用程序在特定的地方写入数据库,你要确保你的应用程序不会在其他任何地方写入数据库,除非你特别期望它.虽然这是一个有效的观点,但我认为值得花时间编写白盒测试而不是黑盒测试.
总之,有两个问题:
您如何看待黑匣子单元测试的概念？
您如何看待我们希望实施该概念的方式？你有更好的想法吗？
unit-testing ×1