当在bash中编写一个琐碎的脚本时，我经常想知道如何使代码可测试。
通常很难为bash代码编写测试，因为它对于取值和返回值的函数是低的，对于在环境中检查和设置某些方面的函数，修改文件系统，调用程序等 – 依赖于环境或具有副作用的功能。因此，安装和测试代码变得比他们测试的代码复杂得多。
例如，考虑一个简单的函数测试：
function add_to_file() {
local f=$1
cat >> $f
sort -u $f -o $f
}
add_to_file.before：
foo bar baz
add_to_file.after：
bar baz foo qux
和测试代码：
function test_add_to_file() {
cp add_to_file.{before,tmp}
add_to_file add_to_file.tmp
cmp add_to_file.{tmp,after} && echo pass || echo fail
rm add_to_file.tmp
}
现在考虑一个稍微更复杂的情况：
function distribute() {
local file=$1 ; shift
local hosts=( "$@" )
for host in "${hosts[@]}" ; do
rsync -ae ssh $file $host:$file
done
}
我甚至不能说如何开始写一个测试…
所以，有没有一个好的方法来做bash脚本中的TDD，或者我应该放弃，把我的努力在其他地方？
所以这里是我学到了：
原文链接：https://www.f2er.com/bash/389842.html>有一些testing frameworks写在bash和bash，
然而…
>这不是Bash不适合TDD(虽然有些
其他语言的想法是更好的适合)，但是
Bash用于的典型任务(安装，系统
配置)，这是很难写和测试
特别难以设置测试。
> Bash中糟糕的数据结构支持使得难以分离
逻辑从副作用，并且确实通常有很少的逻辑
在Bash脚本。这使得很难打破脚本
可测试块。有一些功能可以测试，但是
这是例外，而不是规则。
>功能是一件好事(tm)，但他们只能走得这么远。
>嵌套函数可以更好，但它们也是有限的。
>在一天结束时，主要努力一些覆盖可以
获得，但它会测试不那么有趣的部分代码，
并将保持大部分的测试作为好的(或坏的)旧手册
测试。
Meta：我决定回答(并接受)我自己的问题，因为我无法在Sinan Ünür’s(投票)和mouviciel’s(投票)之间做出选择，同样有用和有见地。我想注意Stefano Borini’s的答案，虽然不是最初我印象深刻，我学会了欣赏它随着时间的推移。他上面提到的他的design patterns or best practices for shell scripts answer(投票)是有用的。
