JavaScript 单元测试最佳实践答案

【问题标题】：JavaScript unit testing best practicesJavaScript 单元测试最佳实践
【发布时间】：2015-08-26 13:30:20
【问题描述】：

这可能是一个广泛而有争议的问题......但我们开始吧。

我以前从未在 JavaScript 中进行过单元测试，我想知道关于其部署的最佳实践是什么。

单元测试本身非常简单（创建自己的单元测试或使用现有的框架，如 QUnit 很简单）。

我的问题是关于部署最佳实践；单元测试代码是否应该部署到生产环境中？

例如：我有一个对象 'person'，其函数为 'getname()'；然后我有相应的单元测试来断言这个名字是我所期望的。

很简单，对吧？...但我从未见过“野外”的 JavaScript 单元测试示例。因此，当人们将他们的工作部署到生产环境中时：

他们是否剥离了单元测试以节省带宽？
是否有特殊的方法来处理单元测试，以免它们进入生产环境？
是否有可用的工具可以让我在本地进行单元测试，但将其剥离用于生产？

我以前从未对 JavaScript 进行过单元测试，所以我不确定我问的问题是否正确。

【问题讨论】：

不要测试 getter 和 setter...
好点。 getter/setter 过于细化。我只是用它作为一个例子。假设它是一个更复杂的功能，通过 3rd-party api 获取数据，一旦我编写了相应的单元测试，是否应该“按原样”简单地部署到生产中？
这可能是一个广泛的，的确。策略因框架/可用工具而异。您是在谈论 node.js 项目，还是像 Angular、Ember 或一些由您的 ASP 页面提供服务的 JavaScript 等客户端。您可能想要更具体一点，以便我们了解应该关注什么开。
实际上都是。它是一个完整的 JavaScript 堆栈。我并没有为创建测试而苦苦挣扎。我对将其部署到生产中特别感兴趣。我以前从未在互联网上见过它（但我也不检查我去的每个网站）。这是因为 JS 开发人员不进行单元测试（简短的谷歌搜索表明很多不）还是在开发和部署之间有一个我不知道的过程？
通常会使用一些工具将源 js 文件压缩/压缩为单个文件。（您可以稍微将其与编译 C/java 源代码进行比较）。测试文件通常被排除在此压缩之外。 @pablochan 在他的回答中提到了这样的构建工具，

标签： javascript unit-testing

【解决方案1】：

是否应该将单元测试代码部署到生产环境中？

没有。

他们是否在剥离单元测试以节省带宽？

是的。将测试部署到生产环境也没有任何好处。

是否有一种特殊的方式来处理单元测试，以免它们进入生产环境？

将它们写入单独的文件中。不要部署这些文件。一个清晰的命名约定会有所帮助，例如所有测试文件都以.spec.js结尾。

是否有可用的工具可以让我在本地进行单元测试，但将其剥离用于生产？

是的。准备分发包时，可以使用Grunt、Gulp.js、Make等跳过测试文件。

【讨论】：

【解决方案2】：

您将永远在生产附近进行单元测试。代码单元不应依赖于环境。

如果一个代码单元在本地开发环境中以一种方式工作，它应该在测试或生产环境中以同样的方式工作。

【讨论】：

【解决方案3】：

测试应始终在生产部署之前在本地运行。

不应在生产部署期间运行测试代码 - 相反，它应该用于在 continuous integration (CI) 或 QA 等测试部署环境中传递构建（查看Jenkins 用于持续集成服务器，karma 用于运行测试，非常适合这些场景）。拥有一个单独的 QA 环境将允许您私下镜像生产并检查发布后遇到的错误。

这很明显，但测试也应该在本地运行。

使用持续集成服务器来管理您的部署。通常的做法是，如果遇到测试失败，则构建失败，这表明应用程序还没有准备好进行生产发布。

然后，您应该使用与 CI 或 QA 环境（假设所有测试都通过）匹配的标记应用程序（假设您使用 Git 标记对快照进行版本控制），并将其用作在您的生产应用程序上签名的指标，表明它已准备好用于生产发布和部署。

您不应在生产部署期间运行测试，而应在生产之前的环境中运行测试。

这当然是过于简单化了，您的情况可能会因您的应用程序需求而异。

【讨论】：