Question

这是一个非常糟糕的代码示例。对于那个很抱歉。我想为myMethod（）编写一个单元测试。这只调用其他方法并返回String str1。我不认为有必要测试此代码。

public class MyClass{
    private String str1;
    private String str2;

    private void m1(){..}
    private String m2(){  
         // do something
        return someString;

    }
    public String myMethod(String s1){
      str2 = s1;
      m1();
      str1 = m2();
      return str1;
    }
}

Answer 1

有多种方法可以编写单元测试。

A）你观察行为。您在测试中创建了一个类的对象，然后调用方法;然后你断言对返回的值。

B）当您的对象使用其他对象时，您可能必须转向模拟框架，例如验证您是否在这些对象上看到了预期的方法调用。

在你的情况下，它实际上取决于m1 / m2的作用。如上所述 - 最好的单元测试是仅检查被测代码的“可观察”行为。像那些例子一样：

@Test(expected=NullPointerException.class)
public void testMyMethodWithNull() {
  new MyClass().myMethod(null);
}

上面会检查当你用null调用你的方法时......抛出一个NPE。

@Test
public void testMyMethodWithEmptyString() {
  MyClass underTest = new MyClass();
  assertThat(underTest.myMethod(""), is("some expected string for empty input"));
}

那个人对EMPTY输入做了一些不同的检查。

所以你通过所有有意义的输入工作。当然，这里的想法是可以通过这种方式检查被测试类的所有可能行为。如果有其他人发挥作用，你必须考虑到它们。但理想情况下，情况并非如此：您应该设计所有代码，以便尽可能轻松地对其进行全面测试;理想情况下，除了这样的测试之外，不需要写任何其他内容。

Answer 2

我完全赞同GhostCat：

[...]最好的单元测试是那些只检查＆＃34;可观察的＆＃34;您正在测试的代码的行为。

因此，只测试您所在班级的公共合同（CUT）。

但是，在极少数情况下，您可能需要测试私有方法，例如：如果您正在使用遗留代码。一种方法是使用PowerMockito：

PowerMockito.verifyPrivate(cut).invoke("m1");

cut是您的CUT的一个实例 - MyClass。

查看这些问题以获取进一步的意见和参考：

Answer 3

“我认为没有必要测试这种[私有方法]。”

是。那是对的。

私有方法不需要任何直接测试。当然，私有方法应该是covered，但由于它们是私有的而不是暴露的API的一部分，因此它们不需要像public方法那样直接进行测试。

本书 - JUnit in Action: Second Edition - 概述了有效使用JUnit的许多策略。实现TDD是确保您的类的非公共功能被测试完全覆盖的一种方法。也就是说，您编写单元测试首先，然后实现您的类以通过这些测试。通过这种方式，您只需编写测试所定义的功能。

如何为调用其他方法的方法编写单元测试？

3 个答案: