单元测试和白盒测试

Question

目前，我正在为完全可见的源代码编写单元测试（我认为这被认为是白盒测试？）。 因此，这不是测试驱动的开发。

阅读这篇文章（ 集成测试和单元测试之间有什么区别？ ）澄清了所有这些内容的目的，但是我仍然对我目前的位置感到困惑。

假设我有一个像这样的方法：

/* Some basic description on what doSomething() does */
public int doSomething(Var someVariable) {
    int someInteger = [code does a bunch of stuff to get this];
    someInteger = someOtherClassObject.doSomethingElse(someInteger);
    return someInteger;
}

现在，我真的不知道doSomething()应该做什么。 该文档还不足以真正告诉我应该基于someVariable输出什么int，并且我对源代码还不够熟悉，无法自己真正提出它。

但我有落实，让我看一下方法，把一些Var作为输入，并按照代码，并声称反对什么，它看起来像它会返回。

public void testDoSomething() {
    ClassWithDoSomething object = new ClassWithDoSomething();
    assertEquals([what it looks like it would return], object.doSomething(new Var([some input would go here]));
}

在某种程度上，我以某种方式模拟了doSomethingElse（）调用和Var构造函数（以及其他外部类依赖项，如果需要的话）。

我不知道这是否是进行这些单元测试的正确方法。 我想我应该隔离该方法，但是我不知道我的断言在确定是否存在错误方面的意义，因为我知道doSomething()方法应该在代码中做什么，以及它的处理方式，因此我写了我的断言以获得结果。

我已经阅读了答案，详细说明了由于方法doSomething()的孤立失败而使单元测试受益的原因。 但是，除了doSomething()的实现发生变化（这意味着单元测试发生变化doSomething()之外，它的单元测试什么时候会失败？

这是不是对源代码不够了解/对源代码的文档不足以仅仅能够知道我应该获得什么输出的问题？

如果[code does a bunch of stuff to get this]实际上只是someVariable + 3 ，其中someVariable是一个int，则当我知道测试将通过时，断言返回值是someVariable + 3是否被认为是有意义的断言在那个实现上？

Answer 1

但是什么时候它的单元测试会失败？

您完全正确； 当doSomething的实现更改时，单元测试将失败。 单元测试的重点是在看似无害的更改实际上破坏了方法时捕获它。

单元测试通常看起来与您发布的代码段相似：

public void testDoSomething() {
    ClassWithDoSomething object = new ClassWithDoSomething();
    object.someOtherClassObject = new MockOtherClass(); 
    assertEquals(4, object.doSomething(new Var("Input that maps to 4"));
}

SomeOtherClass和MockOtherClass实现了一个IOtherClass接口，该接口指定doSomethingElse 。 当您调用MockOtherClass的doSomethingElse方法时，它只是返回输入。

Answer 2

我想说，如果您不知道代码应该做什么，编写单元测试毫无意义。 单元测试是检查给定的某些输入代码是否行为正确。 如果您不知道“正确”是什么意思，那么如何测试呢？ 在编写有价值的测试之前，您必须了解代码的意图。

如果您编写测试以从头重写源代码，则情况会有所不同。 在这种情况下，测试是您可以获得的最佳安全网，因为它们记录了实际行为并保证它不会改变。 但是即使在这种情况下，也不知道代码的作用，很容易错过一些极端情况。

因此，我建议在编写测试之前始终了解代码的意图。