
Show HN: Critic.sh – Simple testing framework for Bash - Karupan
https://github.com/Checksum/critic.sh
======
rubicks
How might one compare/contast critic.sh against the following?

* [https://github.com/djui/bashunit](https://github.com/djui/bashunit)

* [https://github.com/kward/shunit2](https://github.com/kward/shunit2)

~~~
hinkley
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.

------
choward
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.

Anyway, looks good. I like the output.

~~~
Karupan
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!)

------
asymmetric
This looks nice!

One thing I don't like from the examples is `eval`ing a string containing bash
with assert[0], instead of using bash directly.

Is it possible to simply use `[` in tests?

[0]:
[https://github.com/Checksum/critic.sh/blob/bccf5b853409fcf44...](https://github.com/Checksum/critic.sh/blob/bccf5b853409fcf44d95515e9431a625667e224e/examples/test.sh#L28)

~~~
Karupan
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.

------
Karupan
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!

------
verdverm
Just started using bats-core

Some more documentation would be nice

~~~
Karupan
Thanks for the feedback! I just released this yesterday, so I'll be improving
the docs/examples in the days to come.

------
kamranahmed_se
A bit off-topic but I just made this graphic on "Shell vs Bash" for those
interested
[https://twitter.com/kamranahmedse/status/1228700009459220485](https://twitter.com/kamranahmedse/status/1228700009459220485)

~~~
djsumdog
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).

------
Fnoord
Did you mean to upload the directory .vscode (I'm not familiar with VS Code)?

~~~
0xffff2
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.

~~~
Karupan
Exactly this! I like consistency across machines and having the workspace
settings in git makes it easier.

