If you're going to design modular libraries and scripts with best practices, unit tests, etc, for those languages, then you should be doing the same with Bash.
If you're writing production scripts using Bash, you should be following software best practices - don't give me any "it's just Bash" excuses.
Mocking In addition to bats-mock (part of the bats library in the article), there is another mocking approach: https://pbrisbin.com/posts/mocking_bash/ They both have their uses.
Documentation NaturalDocs ( https://www.naturaldocs.org/ ) can happily parse & extract doc comments from your bash scripts & libraries: https://www.naturaldocs.org/ Just define your own language:
https://www.naturaldocs.org/reference/languages.txt/#adding_...
Format: 1.4
Language: bash
Shebang Strings: bash
Extensions: bash sh
Ignore Extensions: bats
Line Comments: #
Argument Parsing Use Docopt ( http://docopt.org/ ) to get modern arg-parsing in your Bash scripts. Don't waste your time trying to roll your own or use the built-in anemic arg-parsing. Shells implementation: https://github.com/docopt/docopts
Use Bash built-ins Stop invoking external processes for features already available in Bash: https://github.com/dylanaraps/pure-bash-bible
More good resources:
* http://www.tldp.org/LDP/abs/html/
* https://www.gnu.org/software/bash/manual/bashref.html
* http://mywiki.wooledge.org/BashGuide
BUT why are you using Bash? Go use a modern language and don't suffer the idiosyncrasies of Bash where you have to re-invent many common libraries already available like JSON parsers, etc.
My favorite Bash replacement is Python + Plumbum: https://plumbum.readthedocs.io/en/latest/ All the convenience of Bash when invoking commands (no more subprocess()!) with the joy of Python.