ZSH-Guide/21_Zsh-开发指南（第二十一篇-测试方法以及编写可测试代码的方法）.md

导读

在正式的场景，代码写完后都是需要测试的，shell 脚本也不例外。但 shell 脚本的特性导致测试方法和其他语言有所不同。

单元测试

作为一种重要的测试方法，单元测试在很多种编程语言程序测试中起到举重轻重的作用。但不幸的是，单元测试基本不适用于 shell 脚本。并不是说 shell 脚本不能被单元测试，而是说单元测试能测试出来的问题很少，投入却很大。为了让 shell 脚本能被单元测试，50 行的代码很可能要改写成 100 多行甚至更多行。更重要的是 shell 脚本严重依赖外部环境，多数问题需要对脚本整体进行功能测试才能发现，而不是对单个函数进行单元测试。对单元测试的精力投入很可能会减少在功能测试的精力投入。

所以不建议推行 shell 脚本的单元测试，这不仅会让开发者很痛苦，也很难减少问题的出现几率，甚至有可能适得其反。

单个脚本的功能测试

Shell 脚本的最小测试粒度是单个脚本。必须保证单个脚本是容易测试的，不能多个脚本耦合太紧密而难以对其中某一个进行单独测试。

有主体逻辑的脚本依赖的外部环境必须是容易模拟的。比如需要从数据库中读取数据，对数据进行处理，然后写入到文件中，这些功能不能在同一个脚本中完成。因为数据库这个外部环境不容易模拟，会导致测试困难。需要把读写数据库的功能独立成单独的脚本，功能尽量简单，测试该脚本时只需要关心数据是否正常读取了出来，格式是否被正确转换等等，而不需要关心处理数据的具体逻辑。处理数据的主体逻辑代码要独立成一个（或者多个）脚本，测试该脚本时，无需准备数据库环境，直接用另一个脚本或者数据文件取代读取数据库的脚本，提供测试数据。如果文件写入的环境复杂（比如文件或者目录结构复杂，或者要写入到分布式文件系统等等），也需要将文件写入的脚本独立出来以便更易于测试。

对有主体逻辑的脚本进行功能测试，不能手动进行，必须写测试脚本，可以自动运行。每次脚本改动后进行回归测试。项目稳定后，可以在每次提交代码后自动运行测试脚本。测试脚本必须覆盖正常和异常情况，不能只覆盖正常情况。异常情况的多少，要根据脚本的复杂度而定。

有复杂外部依赖的脚本，功能必须单一，逻辑尽量简单，代码尽量稳定，不经常改动。比如读写数据库、启停进程、复杂的目录文件操作等有复杂外部依赖的脚本，功能必须单一，只与一个特定的外部依赖交互，提供尽量和外部依赖无关的中间数据，尽量不包含和外部环境无关的逻辑。该类脚本要容易模拟，以便在测试其他部分时不再需要依赖外部环境。

对于有复杂外部依赖的脚本，可以写脚本自动测试，也可以手动测试，测试时需要包含正常和异常的情况，不能只测试正常情况。

集成测试

测试完每个脚本的功能后，需要将各个脚本以及其他程序整合起来测试互相调用过程是否正常。如果功能比较复杂，需要分批整合，测试各个逻辑单元是否能正常工作。在这部分测试中，和外部环境交互的脚本如果逻辑较为简单，可以不参与，用模拟脚本替代。可以手动测试或自动测试。同样不能只测试正常情况。

系统测试

将所有相关组件整合起来，测试整个系统或者子系统的功能。模拟脚本不能参与系统测试，必须使用真实的外部环境。系统测试通常需要手动进行，可以用自动化测试系统来辅助。需要覆盖尽可能多的情况，不能只测试系统的正常功能。

总结

本文简单介绍了 shell 脚本的测试方法，以及编写可测试代码的方法。更多细节需要后续补充。