如何从测试的角度在shell脚本和已编译脚本之间进行选择

Question

有一个小程序，我必须创建一些基本的数据转换/网关功能(从一个地方的网络下载，文本操作，网络上传到其他地方)。由于这部分软件负责提供多个子系统之间的连续数据流，它可能成为链中的单个故障点，因此对其进行彻底的测试是谨慎的。

我最初开始使用这个程序作为shell脚本，因为它看起来非常适合，因为它的功能可以使用普通的命令行程序以一种紧凑的方式实现。

然而，意识到测试的重要性，我想：“作为一个编译的程序重新实现它不是一个更好的解决方案吗？”

这很有可能导致一个更复杂的解决方案，因为不可能或不实际地为所有事情使用现成的库。但我的感觉是，这最终将提供更好的质量代码，因为这将减少在单元测试方面的妥协，特别是在具有集成测试工具的环境中。当然，我在为脚本编写测试方面没有太多经验，所以我可能有偏见。

这与一般意义上编译的脚本和编译无关，当然，其中的里程可能会有所不同，而且双方各有优缺点。对于测试工具来说，这也可能是正确的，因为我确信有一些方法可以彻底地测试脚本。不过，我们可以安全地说的一件事是，随着复杂性的增加，以shell脚本方式实现的项目的概率似乎降低了，我把它留在这里。

因此，在您的经验中，即使是在比较复杂的任务中，避免使用shell脚本也是一个明智的决定，仅仅是因为它看起来可能没有那么有效地测试吗？还是相反，即使我一开始就能选择不使用脚本，也值得学习测试脚本的艺术吗？

Answer 1

下面是shell脚本的一些缺点，这些缺点会让我对“编译”案例做出决定：

• Shell脚本更依赖于执行上下文。因此，这会影响可移植性。可能会发生这样的情况:脚本中使用的所需工具没有安装在您的新位置。当您用编程语言编写脚本时，您可以轻松地将所需的全部打包到单个可执行文件中。
• 很难用shell脚本编写结构良好的代码，这也意味着很难扩展和维护这样的代码。
• 调试shell脚本的难度更大。
• Shell脚本逻辑不能很好地并行化。
• Shell脚本对IDE的支持很差
• Shell脚本的错误处理机制很差
• 因为没有编译阶段，所以只有当脚本崩溃时，您才会了解一些bug。
• 不是用于测试脚本，而是无论如何(shell脚本对恶意影响更敏感)

下面是shell脚本的一些优点：

• Shell脚本占用的资源较少(但并不总是正确的)
• Shell脚本不需要编译阶段，这样您就可以直接到部署脚本的地方，并通过编辑文件来解决问题。
• Shell脚本不需要任何额外的软件来解释这些命令。