测试/ TDDing专用方法

时间:2019-03-16 16:04:37

标签: testing tdd

还有另一篇关于测试私有方法的文章,但是我希望这与规范有所不同。

人们总是想知道私有方法实际上应该是公共的还是将功能提取到可以测试它的另一个类中,或者最终做出其他妥协。

反射类上的许多编程/脚本语言,因此考虑到这一点,为什么我们不能自动化一种使我们的私有方法可测试的方法?例如,假设我们有一个要测试的带有私有方法的类,那么肯定会起作用:

class ClassWeWantToTest {
    private somePrivateMethod([args, ...]) {
        // Do stuff.
    }
}

class ClassWeWantToTest_TestWrapper extends ClassWeWantToTest {

    public somePrivateMethod_test([args, ...])
    {
        return this->somePrivateMethod([args, ...]);
    }
}

可以手动和自动地以允许使用的语言制作此类测试层。甚至可能会有一个了解语法的第三方工具,该工具将解析一个类并生成一个图层。显然,私有方法只会对测试公开。在正常使用中,私有方法保持私有。

为什么还没有完成?这是一个很愚蠢的主意吗?我认为这是因为尚未完成。它对类混乱非常有帮助,因为只是在创建类以提高可测试性。我知道,这将暴露整个课堂,但是那又如何呢?开发人员知道其工作原理,现在可以测试其代码的更多方面而不必盲目工作。开发人员将能够使用带有或不带有包装器的类,从而提供更大的灵活性。

1 个答案:

答案 0 :(得分:0)

  

反射类上的许多编程/脚本语言,因此考虑到这一点,为什么我们不能自动化一种使我们的私有方法可测试的方法?

可以,但是您将优先级放在错误的位置。

TDD的重点是改进您的设计。设计的一个重要元素是,对测试很重要的零件也易于测试/具有成本效益。

写我们一直写的相同的意大利面条代码,但是经过测试,却错过了。

更广泛地讲,如果您有一种“私有”方法,该方法足够复杂,以至于您仅在测试公共接口时就不适应风险,那么这就很明显地暗示着您真正拥有的概念是与封闭方法/类不同。因此,补救措施是重新设计解决方案,以便可以将测试探针放置在所需的位置。

您可能想在Published methods上查看Martin Fowler

  

要说的是,公开发布的区分比更常见的公共-私有区分更重要。