你认为在JUnit测试嘲讽的对象是一个最好成绩的做法？我没有看到很大的优势。当然，如果你有一个不应该在你的测试中考虑的数据库，它是有道理的，但为什么不只是注入该组件的其他实现（如果使用了spring）。测试的一个对象工厂将使这非常容易。我没有太多经验（我们正在使用Mockito），但我已经看到，应用程序代码被修改，以便某些属性可以被嘲弄！在我看来，测试用例不应该改变生产性代码中的这种变化。在JUnit测试中嘲弄对象 - 最佳实践？
那么你觉得这是什么话题？你在嘲笑你的对象或你为什么不这样做？
嘲讽的想法是，你完全隔离您正在测试的东西。然后，当测试失败时，您可以确定问题所在，而无需通过整个类依赖关系树进行搜索。如果你一起测试多个类的行为，那么这不是真正的单元测试。
对象工厂为测试大概使物体与stubbed方法和mocking结构实际上是在测试中使用的通用对象的工厂。但嘲笑提供了很多超过存根做 - 这是马丁·福勒进入细节上这里的区别：http://martinfowler.com/articles/mocksArentStubs.html。
如果您发现嘲讽艰苦，你也发现你做了很多的话，那么就是TDD的告诉你，你的设计可以提高一个典型的例子。
我已经看到，该应用程序 代码被修改，使得一些 性能得到mockable！测试用例 应该从来没有在我oppinion在 生产代码efford这样的变化。
TDD的核心思想是，通过强迫你做所有的代码可测试，可在一般的设计会变得更好。这并不一定意味着只是为了让所有的东西都可以嘲笑，也可能意味着减少耦合，从而减少嘲笑是必要的。如果您认为自动化测试能够提供价值，那么即使您不同意这种理念（我自己也不会100％购买），那么更改生产代码以支持该价值是有意义的（除非它以某种方式严重影响设计）。
减少依赖
值对象不应该被嘲笑
惩戒框架grow-out从必要性。正如Matthew Gilliard所说，如果有某种嘲讽正在进行，那么它表明设计可以改进或缺乏测试焦点。测试会在代码中发现很多问题。
但为什么不只是注入该组件的其他实现（如果使用了spring）。
你必须编写实现。使用嘲笑框架它为你完成。
我已经看到，该应用程序代码被修改，以便一些属性可以嘲弄！在我看来，测试用例不应该在生产性代码中进行这种更改。
如果嘲讽意味着可测试，那么它是另一种方式。例如，在TDD测试中定义了生产代码。
我认为真正的问题是单元测试是否是最佳做法。如果您确信它是这样的话，那么使用嘲讽是必要的，从测试单元与其依赖关系的实现隔离的角度来看。
虽然这与可测性的概念有何关系。复杂的，令人费解的代码基本上是不可测试的，因为它很难理解。具有简洁设计的设计良好的代码通常更易于理解和维护;那为什么要单元测试很难呢？
混淆产生于一些嘲笑工具发现某一任意的限制，例如无法嘲笑final或static方法，或者需要具有测试单元直接使用在测试代码创建模拟对象。其他嘲笑工具没有这些限制，因此不需要“应用程序代码被修改，以便某些属性可以被嘲弄”。随着现代编程语言/平台（Java，C＃，Python，Ruby等）一切是嘲弄;它只是一个在模拟API中暴露这种力量的问题，并且已经为这些语言中的每一种完成了它（为了完全公开，我开发了一个这样的工具）。