我正在为我在公司应用程序中编写的API的实现编写单元测试.这件事还是新手.在寻找关于如何对某些事情进行单元测试的答案时,我遇到了某种模式.它是这样的:
题:
我有这个私有方法我需要进行单元测试.
最受欢迎的答案:
别.
我也遇到过这篇文章,反对单元测试私有方法.
基本上我是如何实现我给出的API是我先编写代码,然后编写单元测试以"尽可能以最坏的方式打破"(正如我的上司所说).一旦我发现有问题,我会在代码中修复它.对我而言,这似乎是OOD和TDD的混搭.这是一种合法的做法吗?
我首先得到这么多private
方法的原因是我需要将更大的代码块分解为方法.由于这些方法只应在此API实现的范围内使用,因此我将它们设置为private
.由于我的团队建立的文件结构要求我将所有代码写入对应于API的单个文件中,因此无法将这些private
方法分成新类并将其设置为public
.
我的上司也希望我也测试这些private
方法.但是,如果方法Assert
上的s public
都成功运行,我开始怀疑这是否真的有必要?
从我的角度来看,如果我对public
方法的测试返回我期望的值,我推断我的private
方法也像我想的那样工作.
或者我错过了什么?
核心要点是:存在单元测试以保证您的测试类表现如预期.
您的类的行为通过可以从类的"外部"调用的那些方法表现出来.
因此,在尝试直接测试私有方法时既没有必要也没有意义.
当然,在运行单元测试时测量覆盖率是公平的 ; 以了解代码中的哪些路径.此信息可用于增强测试用例(以获得更多覆盖); 或删除生产代码(不是必需的).
并与您的问题保持一致:您不使用TDD来实现私有方法.
您使用TDD创建可以自动执行的"合同"的特殊形式.你验证了需要做什么; 而不是它是如何实际完成的.由于TDD方法包括连续重构,因此尤其如此.你编写测试,将它们变为绿色(通过编写生产代码); 然后,在某些时候,您会考虑提高代码的质量.含义:您开始重新测试正在测试的类的内部方面.喜欢:创建更多私人方法,移动内容; 甚至可能只创建内部辅助类等等.但是你继续运行你现有的测试......它们应该仍然有效; 因为如上所述:你写它们来检查外部可观察的行为(尽可能).
除此之外:您应该考虑"模糊化"您的单元测试驱动到代码中的测试数据,而不是担心私有方法.
我的意思是:不要试图手动找到使您的生产代码中断的测试数据,而是尝试像QuickCheck这样的概念,尝试自动完成.
最后的话:如果你的管理层继续抨击"测试私人方法"; 那么作为工程师,你有责任让他们相信他们错了.并且有很多材料可以支持这一点.