Question

考虑以下课程

public class Validator {

    boolean startValiadation(UserBean user){  
        //This method is visible inside this package only        
        return validateUser(user);           
    }

    private static boolean validateUser(UserBean user){
        //This method is visible inside this class only  
        boolean result=false;
        //validations here
        return result;
    }
}

由于上述方法的安全性要求，我以上述方式编写代码。现在我想用Junit编写测试用例。但通常单元测试旨在运用类或单元的公共接口。我仍然可以使用reflection做一些我期待的事情。但我想知道有没有其他方法可以实现我的目标？

Answer 1

但通常单元测试旨在运用类或单元的公共接口。

好吧，我对此并不太教条。我发现，如果你愿意成为“白盒子”并测试非公开成员，你通常可以获得更好的测试深度。虽然有一个滑动规模 - 直接测试私有成员相对比较难看，但您可以轻松地测试包私有方法，只需确保您的测试与类。

（这种方法也鼓励软件包私有类 - 我发现如果你严格坚持测试只是公共API，你通常会养成让所有类公开的习惯方法公开，实际上他们应该包私有。）

在这种情况下，我建议您通过startValiadation方法进行测试。目前调用validateUser但忽略了结果 - 我假设在实际代码中它调用方法并使用结果执行有用的，这在测试中是可见的。在这种情况下，您只需使用各种不同的startValiadation对象调用User，并断言哪些对象应该有效。

Answer 2

你不需要反思。只需将您的测试类放在与此类相同的包中。它不需要在同一个文件夹或同一个项目中。

Answer 3

不，您只有三种选择来测试私有方法：

如果您控制代码，则将访问说明符更改为public只是为了测试方法
否则使用反射。

这可能符合您的利益：

3。使用公共方法测试您的私有方法。

Answer 4

不要孤立地测试这个类。至少在Kent Beck设想的TDD精神中进行的单元测试不是单个类或方法的测试，而只是一个不会对其他测试产生副作用的测试。

此Validator类用于同一包中的其他类。首先使用这些类的公共接口编写失败的测试，然后通过实现验证使其通过。不需要反思。

如果你要单独测试这个类，你可能会在其他类中模拟这个类，并验证是否真的调用了startValiadation()。这样做的缺点是将测试代码与实现代码相结合。我会说：不要这样做。

我最近写了一篇关于此问题的post，在底部有一个链接到Ian Cooper的演示文稿，其中有更深入的介绍。

Junit测试以下场景

4 个答案: