如何避免巧合测试通过

Question

我有以下测试用例：

it('is to show welcome message', () => {
    spyOnProperty(authServiceSpy, 'token').and.returnValue(environment.testAuthenticationToken);

    let teacher: Teacher = authServiceSpy.token.teacher;
    let welcome: HTMLElement = ne.querySelector('#welcome-msg');
    expect(welcome).toBeTruthy();
    expect(welcome.innerHTML).toEqual(`Welcome ${teacher.firstName}`);
});

已修改environment.testAuthenticationToken：

testAuthenticationToken: {
    "type": "teacher",
    "emailVerified": true,
    "teacher": {
        "_id": "0000000000000000000000000",
        "title": "Teacher-X",
        "firstName": "X",
        "lastName": "X",
        "locale": "en-US",
        ...
        "emailVerified": true,
        ...
    }
}

这是相应的模板html

<div id="welcome-msg">Welcome X</div>

[如果我使用的是TDD，因此从测试开始，然后进行使测试通过的最小实现，则我将在HTML X这种情况下用硬编码教师的姓名。测试通过了，尽管在一般情况下实现被破坏了。如果我停止了这一天的工作，第二天又来运行测试，我可能会认为，由于测试通过，所以代码中可能没有问题。

这是预期结果，重构是下一步可能检测到的结果，还是使用随机预期来规避此结果的方法？还是我走错路了？

谢谢。

Answer 1

如果我在这一天停止工作，第二天又来运行测试，我可能会认为，由于测试通过，所以代码中可能没有问题。

对此特殊问题的一个常见答案是改变您的工作习惯，以便一天回家时总会出现测试失败的情况。第二天早上，失败的测试充当书签，使您回到工作的环境。

当然，您通常不会在这种状态下发布代码。

[当肯特·贝克（Kent Beck）在书中描述TDD时，该过程包括他希望编写的测试清单。当他想到新的想法时，他可能会花一点时间写下来，然后继续进行当前的工作。他后来发现的有趣的测试将被排除在列表之外。

如果列表中的所有项目都被划掉，并且您想不出要添加的任何新项目，则完成。

如果您的测试目的是作为文档的目的，那么应该直接阅读已实施的测试列表以发现差距。凯夫琳·亨尼（Kevlin Henney）在MRU清单/ leap年计算/堆栈上的演讲显示了当问题很小时，情况可能会是什么样。

当然，您还可以通过...

测试

代码来发现缺陷。或者，是X以外的其他人第一次使用该代码时报告错误（假设故障导致failure）