|
|
1
15
我不得不强烈反对这个问题。
没有理由使用限制设计选择的模拟工具。EasyMock、EasyMock类扩展、jMock、Mockito等排除的不仅仅是静态方法。这些工具还阻止您声明类和方法
“初始化合作者而不是注入他们”通常是最重要的 设计,以我的经验。如果通过创建从该类实例化的帮助器类来分解解决某些复杂问题的类,则可以利用将特定数据安全地传递给这些子对象的能力,同时对客户端代码(提供高级操作中使用的完整数据)隐藏它们。在公共API中公开此类助手类违反了信息隐藏、破坏封装和增加客户机代码复杂性的原则。 DI的滥用导致了无状态对象的出现,这些对象实际上应该是有状态的,因为它们将 几乎总是 对特定于业务操作的数据进行操作。 这不仅适用于非公共助手类,也适用于从UI/presentation对象调用的公共“业务服务”类。此类服务类通常是内部代码(针对单个业务应用程序),本质上是不可重用的,并且只有少数客户机(通常只有一个),因为此类代码本质上是可重用的 . JMockit 工具箱。我考虑的不是遗留代码,而是设计的简单性和经济性。到目前为止,我取得的成绩使我确信 真的是一个由两个变量组成的函数: 维修性 全部的 |
|
|
2
13
我完全同意可测试性不是最终目标,这是我在开发PowerMock时意识到的事情之一。我也同意编写单元测试是获得良好设计的一种方法。使用PowerMock可能是一个例外,而不是一个规则,至少是一些特性,比如对构造函数的期望和静态模拟。 anti-corruption-layer 这将抽象第三方代码并使其可测试。然而,有时我认为仅仅使用标准API代码就更干净了。javameapi就是一个很好的例子。这里充满了阻止单元测试的静态方法调用。
我们的问题是指定一组最佳实践规则,以供新手在何时使用PowerMock或不使用PowerMock时遵循。创建好的设计真的很难,因为PowerMock为您提供了更多的选择,也许对于初学者来说就更难了?我认为经验更丰富的开发人员更喜欢有更多的选择。 (创办人) PowerMock |
|
|
3
5
我认为你是对的——如果你需要PowerMock,你可能有很臭的代码。把那些静力学处理掉。 然而,我认为你对字节码插装的看法是错误的。我一直用计算机模拟具体的课程 mockito -它使我不必为它编写接口 每一个仅有一个的班 . 那要干净得多。 只有您可以防止代码气味。 |
|
|
4
4
在.NET竞技场上,关于Typemock隔离器,我们遇到了许多相同的问题。 This blog post 我认为,当人们开始意识到可测试性不是最终目标,设计是通过其他方式学习的,那么我们将不再让恐惧支配我们使用哪些工具,或者在相关的时候不使用更先进的技术。 此外,能够根据应用程序需求选择设计方式也是有意义的。不要让工具告诉你如何设计——它会让你别无选择。 (我在Typemock工作,但曾经反对过) |
|
|
5
3
|
|
|
6
0
Powermock提供的过度反射的抽象层看起来很吸引人,但它使测试变得脆弱。更具体地说:
嘲弄
最近遇到了这个 article ,它解决了问题中提出的大部分问题,我想与大家分享一下。
|
|
|
user29759326 · 如何返回递归函数中的最后一个值? 1 年前 |
|
|
malife89 · 将java中的字符串读取为正确的日期格式 1 年前 |
|
|
Tim · 在java中,有没有更快的方法将字节数组写入文件? 1 年前 |
|
|
rudraraj · java中未声明最终变量 1 年前 |
|
|
Bala Ji · 以下BFS的实施效率如何? 1 年前 |