<story><title>Bash_unit – bash unit testing framework</title><url>https://github.com/pgrange/bash_unit</url></story><parent_chain></parent_chain><comment><author>jasonpeacock</author><text>For everyone who&amp;#x27;s saying &amp;quot;if you need unit tests then you should rewrite it in a different language&amp;quot;, you&amp;#x27;re not wrong but you&amp;#x27;re not right either.&lt;p&gt;Bash is a lowest-common-denominator language, available on almost all platforms, with a very stable (old?) API, which makes it ideal for broad distribution &amp;amp; bootstrapping of systems.&lt;p&gt;When you use another other languages, like Python, suddenly you&amp;#x27;re not only worrying about whether Python is installed, but also which version is available, and you still can&amp;#x27;t use anything that&amp;#x27;s not part of the standard library (because then you enter package management&amp;#x2F;dependency hell).&lt;p&gt;I agree that even Python with stdlib-only is still better than Bash, but I guarantee that you&amp;#x27;ll find Bash &amp;gt;=3.0 on every host.</text></comment>
<story><title>Bash_unit – bash unit testing framework</title><url>https://github.com/pgrange/bash_unit</url></story><parent_chain></parent_chain><comment><author>CraigJPerry</author><text>There’s clearly some good thought gone into this - i especially like the ergonomics of the “fake” command and arguments.&lt;p&gt;However, having been down this path myself, i don’t think it’s a great idea.&lt;p&gt;Beyond the hello world examples you start to run into the need to defang commands being tested or getting better visibility of what they’re doing just so you can make a useful assert, you end up LD_PRELOAD’ing shims to intercept calls and it gets a bit horrifying, very quickly.</text></comment>