我还有最后一节课，大概是这样的:
public final class RainOnTrees{
public void startRain(){
// some code here
}
}
我在其他一些类中使用这个类，像这样:
public class Seasons{
RainOnTrees rain = new RainOnTrees();
public void findSeasonAndRain(){
rain.startRain();
}
}
在我的JUnit测试类Seasons.java中，我想模拟RainOnTrees类。我怎么能用Mockito做到这一点?
当前回答
如果您试图在test文件夹下运行unit-test，那么顶部的解决方案是可以的。只要跟着它添加一个扩展。
但如果你想运行与android相关的类，如context或activity，在androidtest文件夹下，答案是你。
其他回答
为运行mockito成功添加这些依赖项:
testImplementation org.mockito: mockito-core: 2.24.5 testImplementation“org.mockito: mockito-inline: 2.24.5”
你不能用Mockito模拟最后一个类，因为你自己不能这样做。
我所做的是创建一个非final类来包装final类并作为委托使用。一个例子是TwitterFactory类，这是我的mockable类:
public class TwitterFactory {
private final twitter4j.TwitterFactory factory;
public TwitterFactory() {
factory = new twitter4j.TwitterFactory();
}
public Twitter getInstance(User user) {
return factory.getInstance(accessToken(user));
}
private AccessToken accessToken(User user) {
return new AccessToken(user.getAccessToken(), user.getAccessTokenSecret());
}
public Twitter getInstance() {
return factory.getInstance();
}
}
缺点是有很多样板代码;好处是您可以添加一些可能与您的应用程序业务相关的方法(如在上面的例子中，getInstance接受用户而不是accessToken)。
在你的例子中，我会创建一个非最终的RainOnTrees类，它委托给最终的类。或者，如果你能让它变成非最终结果，那就更好了。
请看JMockit。它有大量的文档和示例。这里你有一个解决你的问题的例子(为了简化，我添加了构造函数到Seasons注入模拟RainOnTrees实例):
package jmockitexample;
import mockit.Mocked;
import mockit.Verifications;
import mockit.integration.junit4.JMockit;
import org.junit.Test;
import org.junit.runner.RunWith;
@RunWith(JMockit.class)
public class SeasonsTest {
@Test
public void shouldStartRain(@Mocked final RainOnTrees rain) {
Seasons seasons = new Seasons(rain);
seasons.findSeasonAndRain();
new Verifications() {{
rain.startRain();
}};
}
public final class RainOnTrees {
public void startRain() {
// some code here
}
}
public class Seasons {
private final RainOnTrees rain;
public Seasons(RainOnTrees rain) {
this.rain = rain;
}
public void findSeasonAndRain() {
rain.startRain();
}
}
}
由RC和Luigi R. Viggiano共同提供的解决方案可能是最好的主意。
尽管Mockito在设计上不能模拟final类，但是委托方法是可能的。这有它的优点:
如果API一开始就打算将类改为非final类(final类有其好处)，那么不必强制将类改为非final类。 您正在测试API周围装饰的可能性。
在您的测试用例中，您故意将调用转发到被测试的系统。因此，通过设计，你的装饰什么都不做。
因此，测试还可以证明用户只能修饰API，而不能扩展API。
从更主观的角度来看: 我更喜欢将框架保持在最低限度，这就是为什么JUnit和Mockito通常对我来说就足够了。事实上，以这种方式限制有时也会迫使我进行重构。
我猜，您之所以将它作为final，是因为您希望阻止其他类扩展RainOnTrees。正如Effective Java所建议的(第15项)，有另一种方法来保持类接近于扩展而不使其成为final:
删除最后一个关键字; 将其构造函数设为private。没有类能够扩展它，因为它不能调用超构造函数; 创建一个静态工厂方法来实例化你的类。 //这里没有final关键字。 公共类RainOnTrees { 公共静态RainOnTrees newInstance() { 返回新的RainOnTrees(); ｝ 私有RainOnTrees() { //私有构造函数。 ｝ 公共无效startRain() { //这里有一些代码 ｝ ｝
通过使用这种策略，您将能够使用Mockito并使用很少的样板代码保持类关闭以供扩展。
