将部署逻辑迁移到测试套件…中是否很疯狂？？
我们正在使用(并热爱) jest测试框架。我们的大多数测试都是很好的、分区化的、良好代码卫生风格的单元测试。
然而，我们还编写了一些服务级别测试(设置服务器和发出请求)，以及一些更长时间运行的部署测试，用于测试部署堆栈周围的自动化。这些都是隔离的，所以大多数时候您只运行第一个单元测试，但在必要时可以调用(或CI可以)其他较长的测试。
设置这类集成测试可能很棘手，因为有时您必须解决(或破解)您所使用的需要测试的工具的限制--但是，一旦您获得了一个很好的模型，就不会太糟糕了。
现在很多事情都已经建立起来了--我有个疯狂的想法，也许我应该用我们的测试框架来实际执行生产部署过程本身……这样，真正的部署逻辑就更准确地与该逻辑的测试相匹配。在实际部署涉及将各种组件和工具链接在一起的范围内--为什么不以一种可以轻松地利用项目其余部分的代码的方式来表达这些组件和工具呢？正确测试部署过程的变化所需的逻辑可以直接重新使用来实际执行实际部署，并以一种非常好的方式将所有所需的配置旋钮集中/验证。此外，快照可用于断言对部署环境的各种期望，并防止各种意外的变化源.
这个想法听起来很疯狂吗？我真的很想试试..。以前有人这么做过吗？
回答 2
Software Engineering用户
发布于 2017-08-15 19:13:38
请这样看:您实际上所做的是以测试驱动的方式自动化部署过程的步骤，就像您可以以这种方式实现任何其他程序或组件一样。由于您是以“自下而上”的方式这样做的，因此，作为“副作用”，您可以运行部署的构建块，这不仅是为了实际部署，也是为了进行测试。
通过简单地改变你的观点，它听起来不再那么疯狂了，我想？
这里需要考虑的一件事是，当前自动化部署与测试框架有多纠结？如果这两者是强耦合的，那么将它们解耦可能是一个好主意，因此在运行生产部署时，不一定需要安装或对测试框架有特殊的了解。另一方面，也许这两者是强耦合的，但对你来说不是一个实际的问题，那么你可能会把它留在原样上。
Software Engineering用户
发布于 2017-08-15 19:12:14
如果您的“测试代码”用于部署生产代码，那么它不再是测试代码--它是生产代码。
尽管如此，您的想法是合理的，因为在您的测试环境中尽可能最好地反映您的生产环境是一件好事。如果您的测试代码包含更好和更健壮的方法来设置您的生产环境(?)将代码移到生产中也是有意义的。
但是，不要将其视为“使用测试代码进行部署”，而是将其视为“将测试代码集成到生产代码中”。如果您没有任何配置管理或部署团队，我建议您也开始讨论这部分代码库的所有者。
https://softwareengineering.stackexchange.com/questions/355723
复制相似问题
腾讯云开发者
