将系统测试用例包含在应用程序的最终打包产品中是否会导致膨胀或增加风险？

Question

我正在打包一个 rpm 文件，该文件有一个 %postinstall 部分，用于检测某些条件并运行一套单元、功能和系统测试。当我使用代码本身用于诊断的一些相同环境变量时，我得到了一些回击，它暴露了一些内部结构。想法？

更新：我不打算自动运行测试，也不打算将它们的存在暴露给最终用户。我建议该测试包仅适用于该套件所在的任何机器。它使包的最终大小增加了大约 3%，并且需要大量的内部知识才能正确执行。

程序本身是一个库，其他人可以使用并在 API 中公开。事物如何运作的内部知识不是问题。我的主要动机是缺乏合适的测试资源和目标环境的巨大可变性。一些测试非常简单（类似于 configure 确定编译器提供的所有正确功能可能会做的事情）。其他测试涉及更多，它们证明了库应该提供的基本功能。

Answer 1

如果你想避免每次安装都运行的抱怨，至少使用 RPM 的%check 规则。

听起来人们很关心“逆向工程”。那么软件是专有的吗？这似乎是您问题的症结所在。无论如何，测试套件与打包软件分开是很常见的。

但是，您并非不切实际：允许用户自己在他们的系统上运行测试并为您提供结果是与用户建立协作关系的一个重要方面。不幸的是，您遇到了专有商业模式。

也许您可以通过缩减或重写测试和诊断来进行妥协，以仅证明足够的适应度而不会透露太多。我不会放弃你迄今为止所写内容的测试和诊断。

您确实应该提出这样的论点，即用户会很高兴并且对附带完整测试系统的软件包更有信心，并且这些都超过了泄露软件内部结构的任何恐惧。