我最近一直致力于一个已经开始变得相当依赖的项目,并且一直在探索使用AutoMocking容器来清理我的测试并使它们不那么脆弱的想法.
我听说过反对TDD / BDD纯粹主义者使用它们的论点,说明如下：测试主题需要哪些依赖项并不是很明显,或者你可以添加你真正不需要的依赖项.对于使用它们来说,两者听起来都不是特别强烈的论据
从我的角度来看,引入一个将允许我根据需要重构,删除和引入符合业务需求的依赖项,而不必经常返回测试并引入新的模拟/存根以获得编译代码.
AutoMocking被认为是好/坏的做法吗？是否应该使用或不应该使用它？
与任何工具或流程一样,使用它们的时间和错误时间都是正确的.什么都不是银弹.你必须问自己“这会帮助我完成工作吗？”在我们的一天结束时,我们的工作是提供最大的商业价值.
在进行绿地开发时,自动锁定并没有那么有用.一切都是从零开始的,而TDD / BDD技术与“传统”的嘲讽效果很好.从理论上讲,依赖关系并没有那么大的改变,当它们存在时,知道你何时破坏它们可能是件好事.
原文链接：https://www.f2er.com/javaschema/281293.html在进行绿地开发时,自动锁定并没有那么有用.一切都是从零开始的,而TDD / BDD技术与“传统”的嘲讽效果很好.从理论上讲,依赖关系并没有那么大的改变,当它们存在时,知道你何时破坏它们可能是件好事.
当处于维护模式(或处理遗留代码库)时,自动插锁可以证明是非常有益的.例如,您的任务是清理技术债务.这可能涉及大量重构,并且能够将测试与这些更改隔离开来是一个巨大的节省时间.请记住,如果您的代码有很多依赖项,那么它可能会破坏SOLID和SOC,您将(或者至少应该)拥有许多不利用所有依赖项的测试.因此,在这种情况下自动锁定是非常有益的.当然,还有许多其他例子也有帮助.
与任何工具一样,您必须确保它不会变成拐杖.利用自动插件,你可以改变接口和apis willy-nilly显然是一种反模式.但如果使用得当,我发现这对我们的项目团队来说是一个巨大的好处.
它只需要在正确的场景中进行批判性思考和应用.
