What I've learned from writing a Bash testing framework:<p>Bash is inherently untestable.<p>The only way to <i>reliably</i> return something besides a status code is via globals.<p>That means that most functions already rely on previously set global state. Which is one of the reasons that Bash scripts don't scale (the other is non-existent error handling).<p>Do yourself a favor and use a proper scripting language.
I'm a BIG FAN of BATS (<a href="https://github.com/bats-core/bats-core" rel="nofollow">https://github.com/bats-core/bats-core</a>) however sadly BATS is no longer being maintained ––good thing it's still working.
Related from last year: <a href="https://news.ycombinator.com/item?id=19220094" rel="nofollow">https://news.ycombinator.com/item?id=19220094</a><p>2011: <a href="https://news.ycombinator.com/item?id=3408934" rel="nofollow">https://news.ycombinator.com/item?id=3408934</a><p>(Links for the curious. Reposts are ok after a year: <a href="https://news.ycombinator.com/newsfaq.html" rel="nofollow">https://news.ycombinator.com/newsfaq.html</a>)
Used it many years ago and I must admit that while it's easy to start with you can end up with super weird bugs down the line where the only option can be to fork and fix it (after/if you find the issue) :) wouldn't use it again when there are maintained alternatives. Nowadays I just write these integration tests in Go since quite often it's handy to use api client libs to verify some data or prepare some fixtures.
Apologies if this is a dumb question. I glanced at the linked document and it is not obvious to me if this is for testing bash or for testing bash scripts.
Only very tangentially related: <a href="https://batstrafficsolutions.com/" rel="nofollow">https://batstrafficsolutions.com/</a>