如何处理测试和生产代码
如何处理测试和生产代码
原文：https://medium.com/hackernoon/how-to-deal-with-test-and-production-code-c64acd9a062
测试代码和生产代码是不同的，也许它们需要针对每种环境的单独的开发方法
The picture of a yellow lemon surrounded by a bunch of green limes. It definitely stands out as something different.
在使用测试代码和生产代码时，我们可以识别一些模式。出于本文的目的，我们将包含项目逻辑并在生产中运行的系统部分称为“生产代码”。我们称之为"测试代码"项目的一部分，它包含验证应用程序(产品代码)是否如预期的那样工作的测试。这些模式的存在以及它们如何根据上下文而不同，可以使我们以不同的方式处理测试代码和生产代码。
我们都知道测试驱动开发是有用的，至少对于那些能够在适当的环境中正确应用它的人来说是如此。然而，TDD 和测试优先对于编写软件来说都不是必需的。当然，它们提高了质量，但不是必需的。
测试一个内部可能执行多个互连“单元”的功能是可能的。一个“单元”可以是一个模块，一个函数，一个类…任何组成应用程序的东西。虽然产品代码代表了几个相互连接的单元的组合，其中每个单元都应该在某种程度上知道其他单元的存在，但是一个单独的测试不需要知道其他测试的存在。
测试代码和生产代码之间存在差异
通过覆盖系统重要部分的集成测试，最好是使用 TDD 的结果，可以安全地重构整个产品代码，并且非常确信系统仍将按预期工作。考虑到开发人员必须牢记的所有复杂性和熵，这并不意味着重构会很容易，而只是意味着信心很高。
然而，我们不能只是重构所有的测试代码，然后抱最好的希望。我们需要一次重构一个测试，对于每一个测试，我们必须确保我们理解了测试的意图(这就是为什么有时候重复是可以接受的)。之后，通过更改或注释与之相关的产品代码，有意地破坏测试。我们在重构测试代码时，并不像重构生产代码时那样有信心。在这种情况下，额外的护理是必须的。
当重构测试代码时，我们不像重构生产代码那样有信心，因此我们需要小心翼翼地一个一个来做
当我们有一个覆盖良好的系统时，就有可能在生产代码中用低几率的错误来搜索和替换。然而，我们应该极力避免在测试代码中使用搜索和替换，因为没有办法确保不会产生误报。
有些测试运行得非常快，比如单元测试；有些测试运行得非常慢，比如集成测试。速度对于产品代码或测试代码来说都是一个重要的因素，但是它们不能用相同的公式来衡量。这一切都归结于成本，要么是开发者的成本，要么是用户参与的成本。
生产代码是最终产品。根据项目的规模及其影响的系统部分，100 毫秒可以在用户参与度和收入方面产生巨大的差异。对于单个用户来说，这并不重要，但在大范围内，这种影响可能是相关的。
100 毫秒的影响可能与测试代码无关。如果测试很慢，对开发人员的反馈周期会影响生产力。然而，如果有 20 名开发人员，测试代码执行中增加的 100 毫秒的成本可能与服务于数亿用户的应用程序中增加的 100 毫秒的成本不同。
性能在生产代码中与在测试代码中一样重要，但是大多数时候它们并不彼此相提并论
还是关于性能的话题，如果我们正在为 web 开发 JavaScript 应用程序，根据项目的规模，用户下载的产品代码中的每一个字节都很重要。然而，在测试代码中，代码大小是完全不相关的，因为大多数时候它将在开发人员机器或 CI 中本地运行。
有些人在 JavaScript 代码中做了一些折衷来节省字节，并用测试来补偿。有时，在生产代码中复制功能是有意义的，以考虑 GZIP 算法处理字符多次出现的方式，因为它可能会压缩到一个更小或更大的文件中，这取决于它是如何完成的。有时，应用降低代码可读性的技术是有意义的，但相反，这将有助于减少代码的大小。
在生产代码中，有些情况下优化代码大小可能有价值。然而，测试代码永远不会关心它，因此可以作为支持这些权衡的工具
TDD 最著名的倡导者之一 Kent Beck 曾经说过:
我为有效的代码而不是为测试获得报酬，所以我的哲学是尽可能少地测试以达到给定的置信度水平…
—肯特·贝克开启堆栈溢出
为了编写能够工作的软件，我们需要进行测试，否则，将来可能无法工作。项目所有者总是假设默认情况下一切正常，所以我们需要自己假设稳定性是不可协商的。
生产代码和测试代码是有区别的。它可以是复制、重构或表演的形式。然而，一个并不比另一个更重要。
测试代码是不同的，但仍然是必不可少的。