blocks|key|2487911|text|我从一个讨论小组得到了以下答案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2487912|可以从外部文件导入(包括，任何)过程(函数，它的名称)。这是编写测试脚本的关键:将脚本分解为独立的过程，然后将它们导入到运行脚本和测试脚本中，然后让运行的脚本尽可能简单。|blockquote|2487913|这种方法类似于脚本的依赖注入，听起来很合理。最好避免使用Bash脚本，使用更易测试和更少晦涩的语言。|offset|length|2487914|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Dependency_injection^0|0|0|A|4|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|S|8|@]|9|@$G|T|H|U|1|V]]|A|$]]|$1|I|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|J|$K|$5|L|M|N|A|$O|P]]]]

I got the following answer from a discussion group:
<blockquote>
it's possible to import (include,
whatever) a procedure (function,
whatever it's named) from an external
file. That's the key to writing a
testing script: you break up your
script into independent procedures
that can then be imported into both
your running script and your testing
script, and then you have your running
script be as simple as possible.
</blockquote>
This method is like <a href="https://en.wikipedia.org/wiki/Dependency_injection" rel="nofollow noreferrer">dependency injection</a> for scripts and sounds reasonable. Avoiding Bash scripts and using more testable and less obscure language is preferable.

blocks|key|2487835|text|实际上有一个shunit2，一个基于xUnit的基于Bourne的shell脚本的单元测试框架。我自己没有用过，但可能值得一看。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2487836|以前也曾提出过类似的问题：|2487837|Shell脚本的单元测试|unordered-list-item|2487838|在Shell脚本中测试任何协议|2487839|entityMap|0|LINK|mutability|MUTABLE|url|http://github.com/kward/shunit2|1|https://stackoverflow.com/questions/971945/unit-testing-for-shell-scripts|2|https://stackoverflow.com/questions/745266/test-anything-protocol-in-shell-scripts^0|6|7|0|0|0|0|C|1|0|0|F|2|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|I|3|J|5|H|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|K|3|-4|5|6|7|19|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]|S|$5|N|O|P|C|$Q|T]]|U|$5|N|O|P|C|$Q|V]]]]

There is actually a <a href="http://github.com/kward/shunit2" rel="noreferrer">shunit2</a>, an xUnit based unit test framework for Bourne based shell scripts. I haven't used it myself, but it might be worth checking out.

Similar questions have been asked before: 

<ul>
<li><a href="https://stackoverflow.com/questions/971945/unit-testing-for-shell-scripts">Unit Testing for Shell Scripts</a></li>
<li><a href="https://stackoverflow.com/questions/745266/test-anything-protocol-in-shell-scripts">Test Anything Protocol in Shell Scripts</a></li>
</ul>

blocks|key|2487957|text|水龙头-compliant+Bash测试：自动测试系统|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2487958|TAP，testing协议，是测试工具中测试模块之间一个简单的基于文本的接口。TAP作为Perl测试工具的一部分开始了工作，但现在已经有了C、C%2B%2B、Python、Perl、Java、JavaScript等实现。|blockquote|2487959|蝙蝠核|2487960|entityMap|0|LINK|mutability|MUTABLE|url|http://testanything.org/|1|https://github.com/bats-core/bats-core|2|/questions/tagged/bats-core^0|0|3|0|L|6|1|0|0|0|3|2|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]|$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|F|7|11|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|I|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]|Q|$5|L|M|N|C|$O|R]]|S|$5|L|M|N|C|$O|T]]]]

<a href="http://testanything.org/" rel="noreferrer">TAP</a>-compliant Bash testing: <a href="https://github.com/bats-core/bats-core" rel="noreferrer">Bash Automated Testing System</a>

<blockquote>
 TAP, the Test Anything Protocol, is a simple text-based interface between testing modules in a test harness. TAP started life as part of the test harness for Perl but now has implementations in C, C++, Python, PHP, Perl, Java, JavaScript, and others.
</blockquote>

<a href="/questions/tagged/bats-core" class="post-tag" title="show questions tagged &#39;bats-core&#39;" rel="tag">bats-core</a>

blocks|key|2488345|text|我创建了壳类，因为我想要一个易于使用和有用的工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2488346|它是由纯POSIX+shell脚本编写的。它已经测试了许多比shunit2更多的外壳。它有比蝙蝠/蝙蝠核更强大的特征。|2488347|例如，它支持嵌套块、易于模拟/存根、易于跳过/挂起、参数化测试、断言行号、按行执行、并行执行、随机执行、水龙头/JUnit格式化程序、覆盖率和CI集成、分析器等。|2488348|请参阅项目页面上的演示。|2488349|https://github.com/shellspec/shellspec|unordered-list-item|2488350|https://shellspec.info/|2488351|entityMap|0|LINK|mutability|MUTABLE|url|1|https://en.wikipedia.org/wiki/Test_Anything_Protocol|2|https://en.wikipedia.org/wiki/JUnit|3|https://en.wikipedia.org/wiki/Continuous_integration|4|5^0|4|2|0|0|0|1G|3|1|1K|5|2|1Z|2|3|0|0|0|12|4|0|0|N|5|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]|$A|1C|B|1D|1|1E]|$A|1F|B|1G|1|1H]]|C|$]]|$1|H|3|I|5|6|7|1I|8|@]|9|@]|C|$]]|$1|J|3|K|5|L|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|M|3|N|5|L|7|1N|8|@]|9|@$A|1O|B|1P|1|1Q]]|C|$]]|$1|O|3|-4|5|6|7|1R|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|K]]|V|$5|R|S|T|C|$U|W]]|X|$5|R|S|T|C|$U|Y]]|Z|$5|R|S|T|C|$U|10]]|11|$5|R|S|T|C|$U|K]]|12|$5|R|S|T|C|$U|N]]]]

I created <a href="https://github.com/shellspec/shellspec" rel="noreferrer">shellspec</a>, because I wanted a easy-to-use and useful tool.
It written by a pure POSIX shell script. It has been tested with many shells more than shunit2. It has more powerful features than bats/bats-core.
For example, it supports nested block, easy to mock/stub, easy to skip/pending, parameterized tests, assertion line number, execute by line number, parallel execution, random execution, <a href="https://en.wikipedia.org/wiki/Test_Anything_Protocol" rel="noreferrer">TAP</a>/<a href="https://en.wikipedia.org/wiki/JUnit" rel="noreferrer">JUnit</a> formatter, coverage and <a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="noreferrer">CI</a> integration, profiler, etc.
See the demo on the project page.
<ul>
<li><a href="https://github.com/shellspec/shellspec" rel="noreferrer">https://github.com/shellspec/shellspec</a></li>
<li><a href="https://shellspec.info/" rel="noreferrer">https://shellspec.info/</a></li>
</ul>

blocks|key|962293|text|Nikita写了一篇优秀的博客文章，比较了几个不同的Bash测试框架：测试Bash应用程序|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|962294|令人不耐烦的是:尼基塔的结论是使用蝙蝠，但尼基塔似乎错过了蝙蝠核项目，在我看来，这个项目是未来使用的，因为最初的蝙蝠项目自2013年以来就没有得到积极的维护。|962295|entityMap|0|LINK|mutability|MUTABLE|url|https://medium.com/wemake-services/testing-bash-applications-85512e7fe2de|1|https://github.com/sstephenson/bats|2|https://github.com/bats-core/bats-core^0|Z|A|0|0|H|2|1|T|3|2|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]|$A|Z|B|10|1|11]]|C|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]]]

Nikita Sobolev wrote an excellent blog post comparing a few different Bash test frameworks: <a href="https://medium.com/wemake-services/testing-bash-applications-85512e7fe2de" rel="nofollow noreferrer" title="Testing Bash applications">Testing Bash applications</a>
For the impatient: Nikita's conclusion was to use <a href="https://github.com/sstephenson/bats" rel="nofollow noreferrer" title="Bats">Bats</a>, but it appears that Nikita missed the <a href="https://github.com/bats-core/bats-core" rel="nofollow noreferrer" title="Bats-core">Bats-core</a> project which appear to me to be the one to use going forward as the original Bats project has not been actively maintained since 2013.

blocks|key|1012007|text|我不敢相信没有人谈论OSHT！它与水龙头和JUnit兼容，它是纯shell+(也就是说，不涉及其他语言)，它也是独立工作的，而且简单直接。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1012008|测试如下(从项目页面获取的代码片段)：|1012009|#!/bin/bash
.+osht.sh

#+Optionally,+indicate+number+of+tests+to+safeguard+against+abnormal+exits
PLAN+13

#+Comparing+stuff
IS+$(whoami)+!=+root
var="foobar"
IS+"$var"+=~+foo
ISNT+"$var"+==+foo

#+test(1)-based+tests
OK+-f+/etc/passwd
NOK+-w+/etc/passwd

#+Running+stuff
#+Check+exit+code
RUNS+true
NRUNS+false

#+Check+stdio/stdout/stderr
RUNS+echo+-e+'foo\nbar\nbaz'
GREP+bar
OGREP+bar
NEGREP+.+#+verify+empty

#+diff+output
DIFF+<<EOF
foo
bar
baz
EOF

#+TODO+and+SKIP
TODO+RUNS+false
SKIP+test+$(uname+-s)+==+Darwin|code-block|syntax|javascript|1012010|简单的运行：|1012011|$+bash+test.sh
1..13
ok+1+-+IS+$(whoami)+!=+root
ok+2+-+IS+"$var"+=~+foo
ok+3+-+ISNT+"$var"+==+foo
ok+4+-+OK+-f+/etc/passwd
ok+5+-+NOK+-w+/etc/passwd
ok+6+-+RUNS+true
ok+7+-+NRUNS+false
ok+8+-+RUNS+echo+-e+'foo\nbar\nbaz'
ok+9+-+GREP+bar
ok+10+-+OGREP+bar
ok+11+-+NEGREP+.+#+verify+empty
ok+12+-+DIFF+<<EOF
not+ok+13+-+TODO+RUNS+false+#+TODO+Test+Know+to+fail|1012012|最后一个测试显示为"not“，但退出代码是0，因为它是一个TODO。人们也可以设置详细的：|style|CODE|1012013|$+OSHT_VERBOSE=1+bash+test.sh+#+Or+-v
1..13
#+dcsobral+\!=+root
ok+1+-+IS+$(whoami)+!=+root
#+foobar+=\~+foo
ok+2+-+IS+"$var"+=~+foo
#+\!+foobar+==+foo
ok+3+-+ISNT+"$var"+==+foo
#+test+-f+/etc/passwd
ok+4+-+OK+-f+/etc/passwd
#+test+\!+-w+/etc/passwd
ok+5+-+NOK+-w+/etc/passwd
#+RUNNING:+true
#+STATUS:+0
#+STDIO+<<EOM
#+EOM
ok+6+-+RUNS+true
#+RUNNING:+false
#+STATUS:+1
#+STDIO+<<EOM
#+EOM
ok+7+-+NRUNS+false
#+RUNNING:+echo+-e+foo\\nbar\\nbaz
#+STATUS:+0
#+STDIO+<<EOM
#+foo
#+bar
#+baz
#+EOM
ok+8+-+RUNS+echo+-e+'foo\nbar\nbaz'
#+grep+-q+bar
ok+9+-+GREP+bar
#+grep+-q+bar
ok+10+-+OGREP+bar
#+\!+grep+-q+.
ok+11+-+NEGREP+.+#+verify+empty
ok+12+-+DIFF+<<EOF
#+RUNNING:+false
#+STATUS:+1
#+STDIO+<<EOM
#+EOM
not+ok+13+-+TODO+RUNS+false+#+TODO+Test+Know+to+fail|1012014|将其重命名为使用.t扩展并将其放在t子目录中，您可以使用prove(1)+(Perl的一部分)运行它：|1012015|$+prove
t/test.t+..+ok
All+tests+successful.
Files=1,+Tests=13,++0+wallclock+secs+(+0.03+usr++0.01+sys+%2B++0.11+cusr++0.16+csys+=++0.31+CPU)
Result:+PASS|1012016|设置OSHT_JUNIT或传递-j以生成JUnit输出。JUnit也可以与prove(1)相结合。|1012017|我使用了这个库，这两个测试函数都是通过获取它们的文件，然后使用IS/OK和它们的底片运行断言，以及使用RUN/NRUN的脚本。对我来说，这个框架为最少的开销提供了最大的收益。|1012018|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/coryb/osht|1|https://en.wikipedia.org/wiki/Test_Anything_Protocol|2|https://en.wikipedia.org/wiki/JUnit^0|A|4|0|H|3|1|L|5|2|0|0|0|0|0|T|4|0|0|8|2|H|1|S|8|0|0|2|A|F|2|11|8|0|V|2|Y|2|1F|3|1J|4|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]|$A|1I|B|1J|1|1K]|$A|1L|B|1M|1|1N]]|C|$]]|$1|D|3|E|5|6|7|1O|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1P|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|1R|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|1S|8|@$A|1T|B|1U|Q|R]]|9|@]|C|$]]|$1|S|3|T|5|H|7|1V|8|@]|9|@]|C|$I|J]]|$1|U|3|V|5|6|7|1W|8|@$A|1X|B|1Y|Q|R]|$A|1Z|B|20|Q|R]|$A|21|B|22|Q|R]]|9|@]|C|$]]|$1|W|3|X|5|H|7|23|8|@]|9|@]|C|$I|J]]|$1|Y|3|Z|5|6|7|24|8|@$A|25|B|26|Q|R]|$A|27|B|28|Q|R]|$A|29|B|2A|Q|R]]|9|@]|C|$]]|$1|10|3|11|5|6|7|2B|8|@$A|2C|B|2D|Q|R]|$A|2E|B|2F|Q|R]|$A|2G|B|2H|Q|R]|$A|2I|B|2J|Q|R]]|9|@]|C|$]]|$1|12|3|-4|5|6|7|2K|8|@]|9|@]|C|$]]]|13|$14|$5|15|16|17|C|$18|19]]|1A|$5|15|16|17|C|$18|1B]]|1C|$5|15|16|17|C|$18|1D]]]]

I can't believe no one talked about <a href="https://github.com/coryb/osht" rel="nofollow noreferrer">OSHT</a>! It's compatible with both <a href="https://en.wikipedia.org/wiki/Test_Anything_Protocol" rel="nofollow noreferrer">TAP</a> and <a href="https://en.wikipedia.org/wiki/JUnit" rel="nofollow noreferrer">JUnit</a>, it's pure shell (that is, no other languages involved), it works standalone too, and it's simple and direct.
Testing looks like this (snippets taken from the project page):
<pre><code>#!/bin/bash
. osht.sh

# Optionally, indicate number of tests to safeguard against abnormal exits
PLAN 13

# Comparing stuff
IS $(whoami) != root
var=&quot;foobar&quot;
IS &quot;$var&quot; =~ foo
ISNT &quot;$var&quot; == foo

# test(1)-based tests
OK -f /etc/passwd
NOK -w /etc/passwd

# Running stuff
# Check exit code
RUNS true
NRUNS false

# Check stdio/stdout/stderr
RUNS echo -e 'foo\nbar\nbaz'
GREP bar
OGREP bar
NEGREP . # verify empty

# diff output
DIFF &lt;&lt;EOF
foo
bar
baz
EOF

# TODO and SKIP
TODO RUNS false
SKIP test $(uname -s) == Darwin
</code></pre>
A simple run:
<pre><code>$ bash test.sh
1..13
ok 1 - IS $(whoami) != root
ok 2 - IS &quot;$var&quot; =~ foo
ok 3 - ISNT &quot;$var&quot; == foo
ok 4 - OK -f /etc/passwd
ok 5 - NOK -w /etc/passwd
ok 6 - RUNS true
ok 7 - NRUNS false
ok 8 - RUNS echo -e 'foo\nbar\nbaz'
ok 9 - GREP bar
ok 10 - OGREP bar
ok 11 - NEGREP . # verify empty
ok 12 - DIFF &lt;&lt;EOF
not ok 13 - TODO RUNS false # TODO Test Know to fail
</code></pre>
The last test shows as &quot;not ok&quot;, but the exit code is 0 because it's a <code>TODO</code>. One can set verbose as well:
<pre><code>$ OSHT_VERBOSE=1 bash test.sh # Or -v
1..13
# dcsobral \!= root
ok 1 - IS $(whoami) != root
# foobar =\~ foo
ok 2 - IS &quot;$var&quot; =~ foo
# \! foobar == foo
ok 3 - ISNT &quot;$var&quot; == foo
# test -f /etc/passwd
ok 4 - OK -f /etc/passwd
# test \! -w /etc/passwd
ok 5 - NOK -w /etc/passwd
# RUNNING: true
# STATUS: 0
# STDIO &lt;&lt;EOM
# EOM
ok 6 - RUNS true
# RUNNING: false
# STATUS: 1
# STDIO &lt;&lt;EOM
# EOM
ok 7 - NRUNS false
# RUNNING: echo -e foo\\nbar\\nbaz
# STATUS: 0
# STDIO &lt;&lt;EOM
# foo
# bar
# baz
# EOM
ok 8 - RUNS echo -e 'foo\nbar\nbaz'
# grep -q bar
ok 9 - GREP bar
# grep -q bar
ok 10 - OGREP bar
# \! grep -q .
ok 11 - NEGREP . # verify empty
ok 12 - DIFF &lt;&lt;EOF
# RUNNING: false
# STATUS: 1
# STDIO &lt;&lt;EOM
# EOM
not ok 13 - TODO RUNS false # TODO Test Know to fail
</code></pre>
Rename it to use a <code>.t</code> extension and put it in a <code>t</code> subdirectory, and you can use <code>prove(1)</code> (part of Perl) to run it:
<pre><code>$ prove
t/test.t .. ok
All tests successful.
Files=1, Tests=13, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.11 cusr 0.16 csys = 0.31 CPU)
Result: PASS
</code></pre>
Set <code>OSHT_JUNIT</code> or pass <code>-j</code> to produce JUnit output. JUnit can also be combined with <code>prove(1)</code>.
I have used this library both testing functions by sourcing their files and then running assertions with <code>IS</code>/<code>OK</code> and their negatives, and scripts by using <code>RUN</code>/<code>NRUN</code>. For me, this framework provides the most gain for the least overhead.

blocks|key|961960|text|为什么你说测试Bash脚本“很难”？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|961961|下面这样的测试包装有什么问题？|961962|+#!/bin/bash
+set+-e
+errors=0
+results=$($script_under_test+$args<<ENDTSTDATA
+#+inputs
+#+go
+#+here
+#
+ENDTSTDATA
+)
+[+"$?"+-ne+0+]+%7C%7C+{
+++++echo+"Test+returned+error+code+$?"+2>&1
+++++let+errors%2B=1
+++++}

+echo+"$results"+%7C+grep+-q+$expected1+%7C%7C+{
++++++echo+"Test+Failed.++Expected+$expected1"
++++++let+errors%2B=1
+}
+#+And+so+on,+et+cetera,+ad+infinitum,+ad+nauseum
+[+"$errors"+-gt+0+]+&&+{
++++++echo+"There+were+$errors+errors+found"
++++++exit+1
+}|code-block|syntax|javascript|961963|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Why do you say that it's &quot;hard&quot; to test Bash scripts?
What's wrong with test wrappers like the following?
<pre><code> #!/bin/bash
 set -e
 errors=0
 results=$($script_under_test $args&lt;&lt;ENDTSTDATA
 # inputs
 # go
 # here
 #
 ENDTSTDATA
 )
 [ &quot;$?&quot; -ne 0 ] || {
 echo &quot;Test returned error code $?&quot; 2&gt;&amp;1
 let errors+=1
 }

 echo &quot;$results&quot; | grep -q $expected1 || {
 echo &quot;Test Failed. Expected $expected1&quot;
 let errors+=1
 }
 # And so on, et cetera, ad infinitum, ad nauseum
 [ &quot;$errors&quot; -gt 0 ] &amp;&amp; {
 echo &quot;There were $errors errors found&quot;
 exit 1
 }
</code></pre>

blocks|key|962123|text|环氧是我设计的一个Bash测试框架，主要用于测试其他软件，但我也使用它来测试Bash模块，包括本身和纸箱。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|962124|主要优点是相对较低的编码开销、无限的断言嵌套和灵活选择用于验证的断言。|962125|我将讲演与BeakerLib进行了比较，这是Red的一些人使用的一个框架。|962126|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/spbnick/epoxy|1|https://github.com/spbnick/epoxy/tree/master/tests|2|https://github.com/spbnick/carton/tree/master/tests|3|http://slid.es/spbnick/epoxy|4|https://fedorahosted.org/beakerlib/^0|0|2|0|1B|2|1|1E|2|2|0|0|2|2|3|5|9|4|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]|$A|11|B|12|1|13]|$A|14|B|15|1|16]]|C|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]|$A|1C|B|1D|1|1E]]|C|$]]|$1|H|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]|R|$5|K|L|M|C|$N|S]]|T|$5|K|L|M|C|$N|U]]|V|$5|K|L|M|C|$N|W]]]]

<a href="https://github.com/spbnick/epoxy" rel="nofollow noreferrer">Epoxy</a> is a Bash test framework I designed mainly for testing other software, but I use it to test Bash modules as well, including <a href="https://github.com/spbnick/epoxy/tree/master/tests" rel="nofollow noreferrer">itself</a> and <a href="https://github.com/spbnick/carton/tree/master/tests" rel="nofollow noreferrer">Carton</a>.
The main advantages are relatively low coding overhead, unlimited assertion nesting and flexible selection of assertions to verify.
I made <a href="http://slid.es/spbnick/epoxy" rel="nofollow noreferrer">a presentation</a> comparing it to <a href="https://fedorahosted.org/beakerlib/" rel="nofollow noreferrer">BeakerLib</a> - a framework used by some at Red Hat.

blocks|key|1011934|text|让assert.sh试一试：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1011935|source+"./assert.sh"

local+expected+actual
expected="Hello"
actual="World!"
assert_eq+"$expected"+"$actual"+"not+equivalent!"
#+=>+x+Hello+==+World+::+not+equivalent!|code-block|syntax|javascript|1011936|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/torokmark/assert.sh^0|1|9|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

Give <a href="https://github.com/torokmark/assert.sh" rel="nofollow noreferrer">assert.sh</a> a try:
<pre class="lang-bash prettyprint-override"><code>source &quot;./assert.sh&quot;

local expected actual
expected=&quot;Hello&quot;
actual=&quot;World!&quot;
assert_eq &quot;$expected&quot; &quot;$actual&quot; &quot;not equivalent!&quot;
# =&gt; x Hello == World :: not equivalent!
</code></pre>

blocks|key|962136|text|我非常喜欢shell2junit，它是一个从Bash脚本测试生成JUnit-like输出的实用工具。这很有用，因为生成的报告可以被连续集成系统读取，比如用于詹金斯和竹子的詹金斯插件。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|962137|虽然shell2junit没有像shunit2那样提供全面的Bash脚本框架，但它确实允许您很好地报告测试结果。|962138|entityMap|0|LINK|mutability|MUTABLE|url|https://code.google.com/p/shell2junit|1|https://en.wikipedia.org/wiki/JUnit|2|https://en.wikipedia.org/wiki/Jenkins_%2528software%2529|3|https://en.wikipedia.org/wiki/Atlassian|4|https://en.wikipedia.org/wiki/Jenkins_%2528software%2529|5|https://code.google.com/p/shunit2/^0|5|B|0|W|5|1|26|3|2|2A|2|3|2D|3|4|0|G|7|5|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]|$A|11|B|12|1|13]|$A|14|B|15|1|16]|$A|17|B|18|1|19]|$A|1A|B|1B|1|1C]]|C|$]]|$1|D|3|E|5|6|7|1D|8|@]|9|@$A|1E|B|1F|1|1G]]|C|$]]|$1|F|3|-4|5|6|7|1H|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]|R|$5|I|J|K|C|$L|S]]|T|$5|I|J|K|C|$L|U]]|V|$5|I|J|K|C|$L|W]]]]

I quite like <a href="https://code.google.com/p/shell2junit" rel="nofollow noreferrer">shell2junit</a>, a utility to generate <a href="https://en.wikipedia.org/wiki/JUnit" rel="nofollow noreferrer">JUnit</a>-like output from Bash script tests. This is useful because the report generated can then be read by continuous integration systems, such as the JUnit plug-ins for <a href="https://en.wikipedia.org/wiki/Jenkins_%28software%29" rel="nofollow noreferrer">Jenkins</a> and <a href="https://en.wikipedia.org/wiki/Atlassian" rel="nofollow noreferrer">Bamboo</a>.
While shell2junit doesn't provide the comprehensive Bash scripting framework like <a href="https://code.google.com/p/shunit2/" rel="nofollow noreferrer">shunit2</a>, it does allow you have nice reporting of the test results.

blocks|key|2488108|text|试试巴什。这是测试脚本的简单方法。例如，您有do-some-work.sh，它可以更改一些配置文件。例如，将新行PASSWORD+=+'XXXXX'添加到配置文件/etc/my.cfg中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2488109|您可以逐行编写Bash命令，然后检查输出。|2488110|安装：|2488111|pip3+install+bashtest|code-block|syntax|javascript|2488112|创建测试只是编写bash命令。|2488113|文件test-do-some-work.bashtest|2488114|#+Run+the+script
$+./do-some-work.sh+>+/dev/null

#+Testing+that+the+line+"PASSWORD+=+'XXXXX'"+is+in+the+file+/etc/my.cfg
$+grep+-Fxq+"PASSWORD+=+'XXXXX'"+/etc/my.cfg+&&+echo+"YES"
YES|2488115|运行测试：|2488116|bashtest+*.bashtest|2488117|你可以找到这里的一些例子和这里。|2488118|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/pahaz/bashtest|1|https://github.com/pahaz/bashtest/blob/master/test_nginx_logs_counting_unique_ip.bashtest|2|https://github.com/pahaz/bashtest/blob/master/test_wc.bashtest^0|M|F|1K|I|29|B|2|2|0|0|0|0|0|0|2|Q|0|0|0|0|5|7|1|D|2|2|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@$9|1J|A|1K|1|1L]]|E|$]]|$1|F|3|G|5|6|7|1M|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1N|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1O|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|1P|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|S|3|T|5|L|7|1T|8|@]|D|@]|E|$M|N]]|$1|U|3|V|5|6|7|1U|8|@]|D|@]|E|$]]|$1|W|3|X|5|L|7|1V|8|@]|D|@]|E|$M|N]]|$1|Y|3|Z|5|6|7|1W|8|@]|D|@$9|1X|A|1Y|1|1Z]|$9|20|A|21|1|22]]|E|$]]|$1|10|3|-4|5|6|7|23|8|@]|D|@]|E|$]]]|11|$12|$5|13|14|15|E|$16|17]]|18|$5|13|14|15|E|$16|19]]|1A|$5|13|14|15|E|$16|1B]]]]

Try <a href="https://github.com/pahaz/bashtest" rel="nofollow noreferrer">bashtest</a>. It’s simple way to test your scripts. For example, you have <code>do-some-work.sh</code> which changes some configuration files. For example, add a new line, <code>PASSWORD = 'XXXXX'</code>, to configuration file <code>/etc/my.cfg</code>.
You write Bash commands line by line and then check output.
Install:
<pre><code>pip3 install bashtest
</code></pre>
Create tests is a just writing bash commands.
File <code>test-do-some-work.bashtest</code>:
<pre><code># Run the script
$ ./do-some-work.sh &gt; /dev/null

# Testing that the line &quot;PASSWORD = 'XXXXX'&quot; is in the file /etc/my.cfg
$ grep -Fxq &quot;PASSWORD = 'XXXXX'&quot; /etc/my.cfg &amp;&amp; echo &quot;YES&quot;
YES
</code></pre>
Run tests:
<pre><code>bashtest *.bashtest
</code></pre>
You can find <a href="https://github.com/pahaz/bashtest/blob/master/test_nginx_logs_counting_unique_ip.bashtest" rel="nofollow noreferrer">some examples here</a> and <a href="https://github.com/pahaz/bashtest/blob/master/test_wc.bashtest" rel="nofollow noreferrer">here</a>.

blocks|key|2488151|text|也许可以利用这一点，或对以下方面作出贡献：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2488152|工具/工具|offset|length|2488153|它的目的是在TAP协议中写入结果，我认为它对CI是好的，对于那些想要shell环境的人也是好的。我设想一些东西在shell环境中运行，所以有些人可能会认为应该在他们的shell环境中测试它。|2488154|entityMap|0|LINK|mutability|MUTABLE|url|https://thorsteinssonh.github.io/bash_test_tools/|1|https://en.wikipedia.org/wiki/Continuous_integration^0|0|0|5|0|0|M|2|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

Maybe this can be used, or contributed to:
<a href="https://thorsteinssonh.github.io/bash_test_tools/" rel="nofollow noreferrer">https://thorsteinssonh.github.io/bash_test_tools/</a>
It is intended to write results in the TAP protocol which I imagine is good for <a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="nofollow noreferrer">CI</a> and is good for those that want shell environments. I imagine some things run in shell environments, so some might argue it should be tested in their shell environment.

blocks|key|962404|text|我已经尝试过这里提供的许多解决方案，但我发现其中大多数都太笨重，难以使用，所以我构建了自己的小测试框架：https://github.com/SnacOverflow/t-bash|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|962405|它只是存储库中的一个文件，您可以使用一组基本的JUnit样式断言直接运行它。|962406|我已经在几个内部项目中专业地使用了它，并且能够使我们的Bash脚本超级稳定和抗回归。|962407|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/SnacOverflow/t-bash|1|https://en.wikipedia.org/wiki/JUnit^0|1G|12|0|0|N|5|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

I’ve tried a lot of the solutions presented here, but I found most of them too bulky and hard to use, so I built my own little testing framework: <a href="https://github.com/SnacOverflow/t-bash" rel="nofollow noreferrer">https://github.com/SnacOverflow/t-bash</a>
It’s just one file in the repository that you can simply run directly, with a basic set of <a href="https://en.wikipedia.org/wiki/JUnit" rel="nofollow noreferrer">JUnit</a> style asserts.
I’ve used it professionally in several internal projects and were able to make our Bash scripts super stable and regression resistant.

blocks|key|2488356|text|创建一个测试mytest.sh。它用特定的输入调用脚本。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2488357|创建文本文件expected/mytest.stdout。它包含测试的预期输出。|2488358|将它们提交到版本控制(如果有的话)。|2488359|运行测试并将输出重定向到另一个文件：|2488360|mytest.sh+>+actual/mytest.stdout|code-block|syntax|javascript|2488361|然后，我们只需要一个文本差异工具，看看结果偏离哪里。我觉得你可以|2488362|diff+expected/mytest.stdout+actual/mytest.stdout|2488363|entityMap^0|6|9|0|6|M|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|12|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|13|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|14|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|15|8|@]|D|@]|E|$]]|$1|S|3|T|5|N|7|16|8|@]|D|@]|E|$O|P]]|$1|U|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|V|$]]

Create a test <code>mytest.sh</code>. It calls your script with specific inputs.
Create a text file <code>expected/mytest.stdout</code>. It contains the expected output for the test.
Commit them to version control (if any).
Run the test and redirect the output to another file:
<pre><code>mytest.sh &gt; actual/mytest.stdout
</code></pre>
Then just us a text diff tool to see where the results deviate. I think you can just do
<pre><code>diff expected/mytest.stdout actual/mytest.stdout
</code></pre>

blocks|key|962168|text|您可能想看看bash_unit：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|962169|单元|offset|length|962170|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/pgrange/bash_unit^0|0|0|2|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

You might want to take a look at bash_unit:

<a href="https://github.com/pgrange/bash_unit" rel="nofollow">https://github.com/pgrange/bash_unit</a>

blocks|key|962362|text|看看外露。它很简单，可以通过多种语言(Perl、Python、红宝石和Bash选择)和跨平台(Linux和Windows)框架来测试任何命令行应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|962363|entityMap|0|LINK|mutability|MUTABLE|url|https://dev.to/melezhik/command-line-application-tests-made-easy-with-outthentic-j49|1|https://en.wikipedia.org/wiki/Perl|2|https://en.wikipedia.org/wiki/Python_%2528programming_language%2529|3|https://en.wikipedia.org/wiki/Ruby_%2528programming_language%2529^0|2|2|0|J|4|1|O|6|2|V|3|3|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]|$A|V|B|W|1|X]|$A|Y|B|Z|1|10]|$A|11|B|12|1|13]]|C|$]]|$1|D|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]|N|$5|G|H|I|C|$J|O]]|P|$5|G|H|I|C|$J|Q]]]]

Take a look at <a href="https://dev.to/melezhik/command-line-application-tests-made-easy-with-outthentic-j49" rel="nofollow noreferrer">Outthentic</a>. It is simple, extensible by many languages (<a href="https://en.wikipedia.org/wiki/Perl" rel="nofollow noreferrer">Perl</a>, <a href="https://en.wikipedia.org/wiki/Python_%28programming_language%29" rel="nofollow noreferrer">Python</a>, <a href="https://en.wikipedia.org/wiki/Ruby_%28programming_language%29" rel="nofollow noreferrer">Ruby</a>, and Bash on choice) and cross platform (Linux and Windows) framework to test any command line applications.

We have a system that has some Bash scripts running besides Java code. Since we are trying to test everything that could possibly break, and those Bash scripts may break, we want to test them.
The problem is it is hard to test Bash scripts.
Is there a way or a best practice to test Bash scripts? Or should we quit using Bash scripts and look for alternative solutions that are testable?

Unit testing Bash scripts

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们有一个系统，除了Java代码之外，还有一些Bash脚本正在运行。由于我们正在尝试测试所有可能破坏的东西，而那些Bash脚本可能会中断，所以我们想要测试它们。问题是很难测试Bash脚本。是否有测试Bash脚本的方法或最佳实践？还是我们应该停止使用Bash脚本，寻找可测试的替代解决方案？

问单元测试Bash脚本
EN

回答 16

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试Bash脚本EN

回答 16

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试Bash脚本
EN