Never used these, but lemme put my Technology Selector hat on for a moment.
critic.sh seems to support BDD style tests whereas the other two are old-school XUnit style tests.
BDD style tends to scale much higher, declares its test coupling more clearly, and survives refactoring and growing test plans much better, IME. It’s also stupid simple to split large files into several bits by cleaving the tests.
But if I’m writing that much code I might switch to shebangs and use another language that has a better debugger and simpler code sharing. Python. Ruby. Node.
For all the time I’ve been using Bourne shells I’ve hardly touched the actual debugging facilities (instead of echo all over) so my advice is a little biased against big bash.
Sorry to go off topic but one of my pet peeves is things self-described as "simple". What does that even mean? Is it simple to use? Is the implementation simple? Is it lacking features that I'm going to need and regret it later? I think it's most people's goal to make their software user friendly, but let us users decide that.
Also, when coming across a project where other solutions exist, it's nice seeing an explanation of why you created your solution instead using prior art. What inspired that project? That really helps me when trying to decide on something. Some comparisons would also be nice.
I have been considering using a shell testing framework for a while (at the moment I just write tests that shell out). But when I see project this new when others have existed for a while I'm curious to know why it was created. However I get that because it's new, documentation probably isn't the main concern right now. I don't know if you care about adoption or just wrote this for yourself.
Fair points. “Simple” to me means a familiar API, and the fact that I don’t have to install any dependencies. I either add it as a git sub module or just copy the file into my project.
> Also, when coming across a project where other solutions exist, it's nice seeing an explanation of why you created your solution instead using prior art.
> However I get that because it's new, documentation probably isn't the main concern right now
I’ll be working on both very soon (life gets in the way during weekends!)
Since the tests have to capture the return code and output of the expression, it has to be eval'd in the _test function, and hence the string. It will be interesting to figure out how this can be done though.
Might be a little late for this, but I've added why I created this framework to the readme:
I was looking for a Bash testing framework with a familiar API and with coverage reporting. Although there are excellent frameworks like bats-core, shunit2 and bashunit, I wasn't too comfortable with their API (not their fault). Also, I wanted some indication of coverage, so that it can be improved over time.
critic.sh exposes high level functions for testing consistent with other frameworks and a set of built in assertions. One of my most important goals was to be able to pass in any shell expression to the _test and _assert methods, so that one is not limited to the built-ins.
The coverage reporting is currently rudimentary, but it does indicate which lines haven't been covered. It works by running the tests with extended debugging, redirecting the trace output to a log file, and then parsing it to determine which functions/lines have been executed. It can definitely be improved!
Huh. This graphic doesn't feel correct. A shell is also a generic term, so fish, zsh, ksh, dash .. they're all shells. sh is specifically either the Bourne shell or something that's (usually) Bourne shell compatible. (Bash is the Bourne Again Shell; sh with extensions, but still POSIX compliant).
It’s about 50/50 in my experience. Some VSCode users put it in source control so that all of their settings are available by just cloning the repo. Others don’t so that multiple users can have their own junk in the .vscode folder without accidentally checking it in.
* https://github.com/djui/bashunit
* https://github.com/kward/shunit2