What I've learned from writing a Bash testing framework:
Bash is inherently untestable.
The only way to reliably return something besides a status code is via globals.
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).
Do yourself a favor and use a proper scripting language.
I used it for a big project about two years ago, and between it and Shellcheck I had pretty good time maintaining a relatively large Bash codebase (we're talking tens of thousands of lines of code across several distinct components).
Initially I was skeptical, and tried using Node and Mocha for writing tests instead, but calling shell from other languages is pretty cumbersome, and at some point that became very annoying. I gave Bats a try and was pleasantly surprised.
Once one gets used to it Shell is a really good language if the large chunk of your work is calling out external processes and passing the outputs between them. Sure, some language design choices of Shell are arcane and subpar, but with tools like Bats and Shellcheck it's possible to reach comparable levels of developer ergonomics that we all got used to with more popular languages.
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.
Neither. It’s called that because it’s using a dialect/DSL of bash.
It’s a general unit test tool, but working in bash orients Bats towards testing of scripted/automated infrastructure. I’ve used it for tests of Chef/Puppet configuration and found Bats a good fit. Seems odd to find it used as the test framework for a data management tool but clearly it floats their boat.
Bash is inherently untestable.
The only way to reliably return something besides a status code is via globals.
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).
Do yourself a favor and use a proper scripting language.