0

考虑下面的类

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用来做一些我在这里期待的事情。但我想知道有没有其他方法可以实现我的目标？

4

4 回答 4

4

但一般来说，单元测试旨在练习类或单元的公共接口。

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

（这种方法也鼓励封装私有类——我发现如果你严格地坚持只测试公共API，你通常最终会养成将所有类公开和许多方法公开的习惯，而实际上它们应该是包私有的。 )

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

于 2013-08-15T06:19:04.967 回答
2

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

于 2013-08-15T06:16:34.330 回答
0

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

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

这可能会引起您的兴趣：

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

于 2013-08-15T06:15:29.223 回答
0

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

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

如果你要单独测试这个类，你可能会在其他类中模拟这个类并验证它startValiadation()真的被调用了。这具有将您的测试代码耦合到您的实现代码的缺点。我会说：不要那样做。

我最近写了一篇关于这个的帖子，在底部有一个指向 Ian Cooper 的演示文稿的链接，该演示文稿对此进行了更深入的讨论。

于 2013-08-20T01:35:59.040 回答