前端的测试驱动开发？

Question

当我在网上阅读的时候，我看到人们真的很喜欢测试前端的应用程序。他们中的一些人还说，他们永远不会雇用没有测试经验的前端人员。

我知道，当处理大量的计算、逻辑和相互交织的模块时，测试是必要的，这在大多数情况下都不是前端开发的情况。我正在做的这个项目将有几个类似的模块，我会为此编写测试，但是这个应用的其余部分该怎么办呢？

例如，我当前的任务是创建一个AuthGuard服务，我的项目负责人明确表示我需要为它编写测试。在研究它的时候，我发现了许多在我看来毫无用处的例子。

例如，我遇到了这个函数：

canActivate(): Observable<boolean> | Promise<boolean> | boolean {
  if (this.authService.isLoggedIn()) {
    return true;
  } else {
    this.router.navigate(['/']);
    return false;
  }
}

正在以这种方式进行测试：

it('should return true for a logged in user', () => {
  authService = { isLoggedIn: () => true };
  router = new MockRouter();
  authGuard = new AuthGuard(authService, router);

  expect(authGuard.canActivate()).toEqual(true);
});

没门夏洛克！显然，当有if语句时，它将返回true，因为这就是if语句的工作方式。这也不是我见过的更糟的。我看到一个人创建了一个模拟服务，并使用相同的数据进行了模拟api调用，并对两者进行了比较。

我写这封信是想看看我们的大多数行业是不是出了什么问题，还是可能是我？测试驱动的开发是否获得了太多的关注，每个人都在写关于如何做的文章，而没有提到我们可能不需要它呢？

Answer 1

对抗性与抱负型

我想这就是你被绊倒的问题。

在TDD中，流程如下：

1. 写一份有抱负的测试，描述你想要的行为。
2. 在使此测试通过的单元中编写代码，同时保持其他测试通过。
3. 回顾这些愿望，并确保它们也是你所渴望的。
4. 更新你的愿望
5. 重复

当你的老板/经理/团队领导转过身来说应该对它进行测试时(在TDD的背景下)，他们谈论的是这些有抱负的测试。在这种方法中，编写一个描述快乐和不愉快路径的测试是有意义的，即使在最琐碎的情况下也是如此--因为这些不是测试。它们是一份设计文件。也许最好把它们看作是自我检查的属性。

然而，我怀疑你听到的是，你应该写另一种测试--对抗性测试。

在这种测试中，您可以查看一般知识(复选框测试)、规范(黑匣子测试)或实际实现(白盒测试)，并寻找实际的弱点。

• 例如，复选框测试将模糊输入字段。不是因为你知道它的任何具体内容，而是因为它是一种可能发生的一般性攻击，而且你想确保系统能够处理它。
• 例如，黑匣子测试可能会看到当您的pop()和empty()堆栈发生了什么。它表现得好吗？如果它是四倍的pop()编辑呢？
• 白盒测试将查找退出null或设置无限循环的一条语句，并证明这里存在问题。

在这种情况下，测试if是不可能的。这是没有意义的，一个if(bool)是保证工作的。如果没有，那么平台/编译器就会出现问题，而不是代码本身。(这可能是有用的，但也不是重点)。

总是更容易写在前面的渴望测试。否则，感觉就像在重新散列实现，而且感觉就像是的，Manning整件事。

如果您处于这样的位置，请尝试忽略该实现。阅读用户故事，或者查看函数的用户(而不是函数本身)。将期望拼凑在一起，这将从业务(从故事)和使用(从调用它的代码)的角度描绘出可接受的画面。这有助于避免测试指定实现。这也有助于“是男人”的感觉。

相反，对抗性测试只能针对实现进行。我的意思是，你知道如何攻击它，只有当它的事情被知道时。

• 一旦确定输入是一个文本框，那么您就可以编写攻击它的方法。
• 一旦您了解了接口的语义，就可以编写攻击它的方法。
• 一旦要检查实现，就可以编写攻击它的方法。

如果您的任务是编写它们，请注意您可以在开发过程中提供的攻击的深度。另外，要注意你自己对工作的依恋，如果你过于执着，它会导致测试，而不是暴露代码的弱点。

• 如果这是您自己的代码--如果可能的话，请在实现它时和攻击它之间留出时间(几个月是一个好的开始)。
• 利用一般问题的核对清单，根据编写它的开发人员的知识进行调整(如果这是您自己诚实地记录和概括您倾向于提出的问题的话)。
• 让其他人去查一下密码。(并将这些问题添加到清单中)。
• 看看已经写好的测试，并询问测试是否会通过更进一步来揭示一些东西。
• 看看系统中已知问题的日志，它们是成功对手的面包屑。