Question

最近，我被分配了一个故事，用于对我的队友进行的变更进行同行测试。我很困惑，因为他已经编写了自己的测试用例来测试代码。那我为什么要做同样的代码测试呢？我也是开发人员而非QA 我有类似的问题我想交叉验证测试用例吗？同行测试的目标是什么？怎么做？

是否有相同的参考文章或文章？

Answer 1

我同意David Whiteman的看法，在其他开发者的测试和你自己的测试之间，每个人都可能会覆盖其他人的盲点。但是，它不仅涉及代码覆盖，还涉及测试设计。

我最近两次单元测试的经验＆＃34;编程介绍＆＃34;类型课程表明，即使是重叠测试也可以有价值 - 在针对您自己的代码编写测试时，将测试结果与测试实现分离起来可能更难。实际上，一个课程鼓励将实现写入测试，当更改时，即使行为正确，也会发生级联故障。

为了澄清我的意思，常见的措辞是"test the interface, not the implementation."在为代码设计测试时，你应该仅依赖于接口的契约代码应该提供给其他课程。例如，访问其测试的对象的成员变量的测试应该使用getter和setter，或者不使用，因为变量可能被重命名甚至删除。如果有问题的成员变量是一个对象，它甚至可能会改变类型，不要介意更改其成员变量的类型。

考虑针对以下类编写测试，为简单起见，它恰好是一个自制堆栈。

public class HomemadeStack {
    private Object[] theStack;
    @postcondition: stack is not empty, and contains one more element
    public void push(Object o) {
        // implementation specific to an array
    }
    @precondition: stack is not empty
    @postcondition stack contains one less element
    public Object pop() throws StackUnderflowException {
        // implementation specific to an array
    }
    @postcondition: the stack is empty (isEmpty() will return true)
    public void clear() {
        // again, implementation specific to an array
    }
    @returns: true only if there are no objects on the stack
    public boolean isEmpty() {
        // again, implementation specific to an array
    }
}

如果您不得不更改访问修饰符以执行测试，至少根据我的经验，这是一个好的迹象，表明您的测试错误。 HomemadeStack 中的变量theStack应该是私有的。前面提到的课程让我们编写如下的测试，其中testStack位于一个非空的HomemadeStack实例中：

void testClearMethodResultsInEmptyStack {
    testStack.clear();
    assert testStack.theStack.size()==0;
}

此测试假定实施过多。它还需要开发人员给theStack更宽松的访问修饰符来测试外部类。但是，编写这样的测试非常容易，然后编写清晰的方法来满足测试要求。它通过了，所以这是一个问题吗？那么，列出上述测试中固有的一些实现假设：

在HomemadeStack中存在一个名为theStack的变量
无论theStack是什么类型的变量，它都是一个带有size（）方法的对象
最重要的是，＆＃34;清除＆＃34;的底层数据结构堆栈的大小为0，而不是与清除之前的大小相同，除非使用＆＃34;第一个可用的＆＃34;指针更新，或其他一些方法。

现在，假设您被告知要转换HomemadeStack以在内部使用链接列表，并将变量命名为＆＃34; theList。＆＃34;即使新的实现正确地推送，弹出，清除和检查空白（即，实现了接口的合同），进入测试的任何实现假设都不会存在！所以现在你已经写了一个没有测试的工人阶级，但没有人能说出问题所在。接下来会有多少小时的恐慌和额外的工作？

为了在没有这些额外假设的情况下测试界面，我在另一门课程中被教导要依赖isEmpty（）和clear（）的契约：

void testClearMethodResultsInEmptyStack {
    testStack.clear();
    assert testStack.isEmpty();
}

还可以依靠clear（）来测试pop（）在合同被破坏时抛出StackUnderFlowException等等。这是对界面的测试，而且它更加健壮。如果你退步了＃34;从正在测试的代码中，可以更轻松地编写“退后一步”的测试。太

作为一种事后的想法，我越是反思它，我就越相信编程课程能够让我接近以测试为导向的开发方式。＆＃34;错误的方式。我试图教会学生很好地解释为什么存在最佳实践，并且在事情发生之前，当他们陷入不太理想的实践时会产生非常糟糕的感觉。另一门课程教授TDD有多少人会考虑＆＃34;正确的方式，＆＃34;但是让我们的学生没有第一手的经验，为什么它是最好的。

Answer 2

我希望能够帮助捕获开发人员单元测试不完整的区域。作为开发人员，在编写单元测试或运行临时测试时，我们都有盲点。

同行测试 - 任何好的参考？

2 个答案: