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.
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.
Anyway, looks good. I like the output.
> 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!)
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!
One thing I don't like from the examples is `eval`ing a string containing bash with assert, instead of using bash directly.
Is it possible to simply use `[` in tests?
Some more documentation would be nice