模拟私人领域作业的最佳技术/解决方案？

Question

TDD和Mockito在这里测试新人..。最近，我发现了一些私人领域的模仿者，我正试图把我的想法弄清楚。

很可能我在这个特定问题上的想法都是错误的，但我经常发现，我想要测试的情况是，调用特定方法导致分配了一个私有字段:在调用之前是null，调用之后，它被设置为任何类的实例。

当您开始运行测试方法时，模拟的私有字段是所讨论类的子类，因此显然对null的测试是没有意义的/不起作用的。同样，如果您的方法导致此字段的赋值，这意味着模拟变量已被一个真正的实例所取代。因此，即使调用了方法，也不会导致与模拟变量的任何交互。无论如何，如果测试只是检查创建和分配，那么您没有理由在测试中与其进行任何交互。

显然，一个答案是在app类中创建一个public get()方法或一个public create()方法。但这给了我一种不好的感觉，因为这显然只是为了测试目的。

顺便提一句，在TDD，有很多人无疑比我更有经验，他们会说我的粒度太细了，不应该测试像字段分配这样具体的东西。但是我对TDD最极端的方法的理解是“不要在没有测试的情况下编写一行代码”。在这个阶段，我真的要尽可能地坚持下去。有了经验，我可能会对如何以及何时偏离这一原则有更多的了解。

只是在我看来，字段的赋值与任何其他类型的事件一样值得(宿主类的类事件)，例如，一旦将实例分配给该字段，就会调用该字段上的方法。我们难道不能用某种方式测试它吗.？在这种情况下，Mockito的专业人士认为这可能是一件合法的事情，他们会做些什么呢？

后来.

法比奥的评论突显出一种紧张，作为一名新人，我感到困惑的是，“不写一行而不做测试”和“只测试公共方法”之间的紧张:这不可避免地会暴露出比我想要的更多东西，纯粹是为了测试。

他所说的“随时改变测试”我也发现了问题:如果我们注入模拟的私有字段并使用它们，那么如果我们更改“实现细节”，那么我们就必须更改测试。这个想法也没有让我感到恐惧:人们意识到了改变的需要，你看了你现有测试方法的非常有解释性的名字，决定哪些测试方法不再适用，当然你创建了新的测试方法。测试代码，就像应用程序代码一样，必须随时改变，对吗？

测试代码不像某种模具，它引导和约束应用程序代码，但同时也可以脱离它吗？通过Mockito允许我们模拟私有字段一种特权形式的访问已经被授予..。谁能说这种特权访问应该扩大到什么程度呢？

甚至更晚.

杰夫·鲍曼( Jeff )认为，这是一个带有this的dup。我并不完全相信，因为我问的是一件非常具体的事情，可能会有一个具体的答案(一些探测任务的Mockito方法)。但他的回答似乎很全面，我正试着完全理解.包括整个依赖注入..。你似乎必须在“扭曲”你的公共界面中做出妥协，这样才能使应用程序类像你想要的那样可测试。

Answer 1

简单示例:您需要编写一个类Class1，它有两个方法Method1和Method2，它们返回由某些Helper类提供的值。

1. 第一种方法的测试开始写测试-它不会编译
2. 产品创建类Class1和Method1编译ok和测试失败
3. 在Method1中创建新的Helper实例，并调用一些返回期望值测试通过的方法。
4. 测试为相同的Method1创建另一个测试用例-测试失败
5. 产品在Method1中进行更改以满足这两个测试用例-测试是绿色的。
6. 生产在Method1中进行一些重构，如果您看到可能性测试必须保持绿色。
7. Method2的测试创建测试，它将更新一些公共字段Field1 of Class1 -将不会编译
8. 生产创建方法Method2和Class1中的字段Field1 --编译- ok，测试失败
9. 产品在Helper中创建Method2类的新实例，调用它的方法，并使用期望值测试通过更新Field1。
10. 为Method2创建另一个测试用例-测试失败
11. 产品在Method2中进行更改以满足这两个测试用例-测试是绿色的。

现在您已经实现了所需的行为，并注意到Method1和Method2都创建了Helper类的实例。

1. 因此，您决定声明Helper类型的私有字段，并在这两种方法中使用它--所有测试都失败--因为您的私有字段没有实例化。
2. 生产-在构造函数中实例化新实例-所有测试都是绿色的。

稍后，如果您决定将Helper类的创建移到外部，并将其作为构造函数的参数传递给Class1，您只需更改生产代码，测试将显示您在不更改测试的情况下破坏任何内容。

我回答的要点是，如果你认为“我想写这行代码--我怎么能测试它”--你现在就会遇到这种情况。

试着先想一想你想测试什么，然后写完测试，想想如何实现它。