为什么要从生产环境中的代码库中删除 QA ID答案

【问题标题】：Why remove QA IDs from the code base in production为什么要从生产环境中的代码库中删除 QA ID
【发布时间】：2019-05-12 15:25:34
【问题描述】：

在我们正在开发的 React 应用程序中，我们使用 QA ID 进行 Selenium 测试。

将它们留在生产（实时）代码库中是不好的做法吗？

如果是这样，为什么？是否只是试图保持 TTFB（第一个字节的时间）低？

更多上下文：

例如。

const automationTags = (givenTag) =>
  (IS_PROD || !givenTag) ? {} : { 'data-qa': _.kebabCase(givenTag) }

用法：

...dataQa 是 React 组件中使用的 prop。

【问题讨论】：

如何使用这些 ID 编写自动化测试，并在这些 ID 已被删除的情况下针对生产运行它？那么您不是针对生产运行自动化吗？
将在部署到生产之前运行测试
删除 QA ID 后恢复的总 kb 是多少？我的猜测是它可以忽略不计。如果不是，那么您的 ID 可能太多。我想我不明白你的问题......如果你的开发人员正在删除它们，问他们为什么。为什么在生产中使用 ID 是一种不好的做法？你看过其他制作网站吗？它们充满了ID等。
@JeffC 这正是我的观点。我们被告知我们应该删除它们，但 TTFB 似乎没有足够的理由。
@ArildAndreassen 只需将示例中的 automationTags 覆盖为 () => {} 即可实现

【解决方案1】：

我可以看到许多留下 ID 的原因。

它降低了代码的复杂性。与其在代码库中包含所有这些逻辑是否包含 ID，不如简单地存在 ID。删除它们可能很容易，但是当您将 ID 的数量相乘时，包含的大量代码几乎没有任何好处。
它提高了各种环境之间的保真度。当您针对您的测试环境运行自动化测试时，您可以相当肯定它将是用于生产的相同代码，而不是它的另一个变体。
它允许您针对生产环境运行自动化。您现在知道它可以正常工作，而不是假设它在部署后工作。你知道他们怎么说假设正确吗？
您的客户不会滥用 ID。如果您的客户正在检查页面/代码，只需知道元素的 ID 并无害。
不必包含特定的 QA ID，最好只使用实际的 ID、类名和常规 CSS，这样您就不需要特定的 QA ID

以上所有因素都超过了将它们留在其中的风险。我认为没有任何性能提升是可衡量的。

话虽如此，实际测量它是说服开发人员不需要删除它们的最佳方式。例如，Chrome 的开发者控制台有一种方法可以测量页面负载以及资源的去向。如果您转到性能，您可以记录页面加载并查看加载页面所需的内容。将生产环境与测试环境进行比较应该可以为您提供更多信息。

【讨论】：