Question

我想使用Mockito对一个方法进行单元测试，该方法调用不同类的其他方法，并且该其他方法包含一些共享的首选项操作。

这是我要测试的方法

public boolean isPersonAvailable(Context context) {
    Person person = new Person();
    return person.loadPerson(context)!= null;
}

这是我的Person类的结构，并且Person类依赖于另一个类的另一个方法

class Person{
    public  Person loadPerson(Context context) {
        SharedPreferenceProvider sp = new SharedPreferenceProvider();
        sp.read(context,"any key");
        return new User;
    }
}

这是我的SharedPreferenceProvider类的结构

class SharedPreferenceProvider{

       public  String read(Context context, String key) {
        SharedPreferences preference = context.getSharedPreferences("AppID", AppConstants.SAVE_MODE);
        return preference.getString(key, EMPTY_STRING);
    }

}

如何对具有如此多依赖性的方法进行单元测试？

Answer 1

您的问题是您的被测方法确实new Person()。

基本上，这会影响您进行合理的单元测试的能力。您可以通过使用PowerMock（ito）或JMockit来解决设计缺陷，或者通过避免调用来改善设计。换句话说：阅读有关依赖注入的信息。这样一来，您已经可以使用一些Person对象。然后，您可以简单地预先模拟该对象，并使它的方法返回进行合理测试所需的一切。

您的受测试代码对Person对象只有一个依赖。消除这种情况（通过使您的代码与模拟的Person对象进行交互），问题就解决了。

Answer 2

通过单元测试，您尝试在隔离的代码中查找错误。但是，方法isPersonAvailable仅包含与其他类，例如Context和Person的交互。如果此方法中存在错误，则它们将取决于与其他这些类的交互级别：您是否在调用Person的正确构造函数？来自null的{{1}}返回值是否真的表明该人没有空，还是以其他方式发出信号？

您将永远不会在模拟中发现这样的交互错误：如果您误解了其他类的工作方式，则会根据自己的错误理解来实现模拟。因此，应该使用集成测试而不是单元测试来测试类似person.loadPerson的方法。

也就是说，即使与这种特定方法无关紧要，学习“依赖注入”的建议也肯定是好的。您可能还会发现寻找“控制反转”很有用。

调用不同类的其他方法的方法的单元测试

2 个答案: