几个问题:
1.) 你是否对发布代码进行单元测试?
2.)如果是这样,那么您是否保留这些单元测试完整,以便测试本身存在于生产环境中?
我在 #1 中看到了值,但是在生产中创建对例如 NUnit 程序集的依赖项是一种“好习惯”吗?
给我你的想法。
几个问题:
1.) 你是否对发布代码进行单元测试?
2.)如果是这样,那么您是否保留这些单元测试完整,以便测试本身存在于生产环境中?
我在 #1 中看到了值,但是在生产中创建对例如 NUnit 程序集的依赖项是一种“好习惯”吗?
给我你的想法。
以上是我的一般规则(我通常部署给非技术用户)。但是我确实有一个例外,它是一个编程实用程序,它使用大约 130 个测试脚本进行了单元测试。因为测试脚本兼作示例,所以我将它们与生产版本一起部署,因此它们增强了现有文档。
使用开源代码部署测试绝对值得。它允许人们使用、修改和提交补丁,同时能够运行成功通过的测试以允许发布原始工件。
是的,是的,发布版本和调试版本之间的应用程序行为可能不同,因此作为发布过程的一部分,发布版本必须通过其所有单元测试。
是的当然!单元测试在所有构建配置上运行。
单元测试始终是完整的,但这并不意味着交付的组件依赖于与测试相关的任何内容。测试总是在并行程序集中(在相同的构建环境中)编写,然后测试生产程序集。并行组件不发货,因为它只包含测试。
取决于项目。是的,第 1 点。遵循所有内容都应检查到源代码控制中的原则,并且让新开发人员开始工作应该很简单。使它们成为代码库的一部分。新人可以进行检查并运行测试。
它们是否部署到生产环境是另一个问题。我还没有在那里工作过需要它们的项目。Rails 的部署模型(通常)只是在生产机器上检查整个项目,所以是的,它们就在那里。Java/Maven 项目有一个完整的构建/打包步骤,通常在构建最终的 .war 文件时可以删除单元测试。
无论哪种方式,您都不希望它们运行。在今天的环境中,他们是否在那儿建站并不重要——内存和磁盘非常便宜,这真的不是问题。我听说过你不希望生产服务器上的测试代码这样就不会有运行它的风险的论点,但我还没有听说过这种情况会真正发生的情况。