Java 测试接口是否应始终与功能接口相同？

这里是TDD新手。我知道我们“测试接口而不是实现”，但是否有理由使用子类Mock和受保护的方法来测试X类的“测试接口”，这可能是X类的公共方法定义的功能接口的超集

假设我有一门课是这样的：

class IndexManager {
    IndexManager( File file ){
        ...
    }

    public void someFunctionalMethodUsedByOtherClasses(){
         ...
    }

}

@RunWith(MockitoJUnitRunner.class)
public class IndexManagerTest {
    ...

    class SubclassMockIndexManager extends IndexManager {
        SubclassMockIndexManager( File file ){
            super( file );
        }

        @Override
        protected IndexWriterConfig createIndexWriterConfig( Analyzer analyser ){
            return super.createIndexWriterConfig( analyser );
        }

    }

    @Spy
    @InjectMocks
    SubclassMockIndexManager injectedSpySM_IndexMgr = new SubclassMockIndexManager(tempFile);

在我的测试课上，我是这样做的：

class IndexManager {
    IndexManager( File file ){
        ...
    }

    public void someFunctionalMethodUsedByOtherClasses(){
         ...
    }

}

@RunWith(MockitoJUnitRunner.class)
public class IndexManagerTest {
    ...

    class SubclassMockIndexManager extends IndexManager {
        SubclassMockIndexManager( File file ){
            super( file );
        }

        @Override
        protected IndexWriterConfig createIndexWriterConfig( Analyzer analyser ){
            return super.createIndexWriterConfig( analyser );
        }

    }

    @Spy
    @InjectMocks
    SubclassMockIndexManager injectedSpySM_IndexMgr = new SubclassMockIndexManager(tempFile);

并在其中制作一种测试“非公共接口”（又称“测试接口”）的方法：

作为响应，要将红色变为绿色，我将修改我的应用程序类，如下所示：

class IndexManager {
    IndexManager( File file ){
        ...
    }

    // added as part of normal red-green TDD development cycle
    protected IndexWriterConfig createIndexWriterConfig( Analyzer analyser ){
        ... // make IndexWriterConfig object

        return indexWriterConfig;
    }

    public void someFunctionalMethodUsedByOtherClasses(){
         ...
    }

}

---

只是我感到困惑，为什么TDD开发周期应该必须局限于暴露于所有其他类的测试方法…

假设你有一个

函数，它由
函数b
和
函数c
组成

如果您只能测试最终结果，即
function
，那么同时测试
functionB
和
functionC
，将浪费时间。只要
function
通过测试，就不需要测试其他功能

我的示例中的
功能类似于测试接口

或者用外行的话说：这就像只要水从“管道末端”流出，达到你预期的准确程度，那么你就没有必要每2英尺测试一次水的流量

虽然决定权仍在你

编辑
为了避免为
functionB
和
functionC
编写测试，最好先编写
test\u function
，一旦它变为绿色，就从那里开始。您的
测试功能B
和
测试功能C
可能永远不需要。编写
testfunctionC
和
testfunctionb
将使其更加困难，并使您需要编写所有三个测试。
谢谢。。。这就是我所谓的“纯粹的TDD”答案。在这个“学派”中，显然有一个很大的哲学承诺，即课堂的内部运作是“无关的”。对于像我这样的TDD新手来说，问题在于另一个“重要的TDD指令”：永远不要在没有测试的情况下编写一行代码。我目前发现这两个基本TDD规则之间经常存在紧张关系@没有有效点。我完全明白。我想你是在学教程什么的。也许这个人教你如何测试一切只是为了教你。不是为了在一个真正的项目中真正做到这一点。但如果不是：你提到的两个不一定是相互对立的。我的意思是，在这种方法中，你永远无法测试一切。它变得笨重和费力。在这一点上，你们必须有选择地进行测试。我建议你们看一下视频。它可能不100%适合你，但它有助于建立TDD心态：）@MikCorvent实际上我正在从书中学习：）…无论如何，作为一种解决方法，你可以先编写test\u functionA，这就足以让你不编写任何test\u functionB或test\u functionC。因为你是绿色的。但是，如果您编写测试函数B或测试函数C，那么您必须编写所有3。。。有用：我逐渐走向更大的启蒙。但正如你正确猜测的那样，我已经读过几本书了。从实际操作的角度来看，迄今为止最好的方法可能是“在测试的指导下开发面向对象的软件”。我犯的许多新手错误之一可能是让我的应用程序类承担了太多的责任。拆分成更小的类会强制更多方法的公共可见性（事实上，通常包private就足够了，但是创建具有这种可见性的测试类会限制您的测试目录结构…）。