您使用什么样的实践来使您的代码更适合单元测试？
在现实世界中的脚本通常被用来调用诸如实用程序find,tar,cpio,grep,sed,rsync,date等含有很多选择一些比较复杂的命令行.有时构造和使用正则表达式或通配符模式.
一个例子:这通常是由cron中定期调用的shell脚本必须从一台计算机的一些巨大的目录树镜像到另一个使用该实用程序的任务rsync的.应该从镜像过程中排除几种类型的文件和目录:
#!/usr/bin/env bash
...
function mirror() {
...
COMMAND="rsync -aH$VERBOSE$DRY $PROGRESS $DELETE $OTHER_OPTIONS \
$EXCLUDE_OPTIONS $SOURCE_HOST:$DIRECTORY $TARGET"
...
if eval $COMMAND
then ...
else ...
fi
...
}
...
正如Michael Feathers在其着名的书"有效地使用遗留代码"中所写,一个好的单元测试运行得非常快,并且不会触及网络,文件系统或打开任何数据库.
根据Michael Feathers的建议,这里使用的技术是:依赖注入.这里要替换的对象是实用程序rsync.
我的第一个想法:在我的shell脚本测试框架(我使用bats)中,我操作$PATH的方式是找到一个模型 rsync而不是真正的rsync实用程序.此模型对象可以检查提供的命令行参数和选项.与此测试脚本部分中使用的其他实用程序类似.
我之前在脚本编写方面遇到实际问题的经验通常是由文件或目录名中的特殊字符引起的错误,引用或编码问题,ssh密钥丢失,权限错误等等.这种类型的错误将逃脱这种单元测试技术.(我知道:对于其中一些问题,单元测试根本不是治愈方法).
另一个缺点是为复杂的实用程序编写一个类似的模型 …