Clarify standard for "Zero Dependency and implemented in Bash" section? about testing-in-bash HOT 5 CLOSED

Hi @abathur

Sorry for the late reply.

I don't mean to suggest that you need to census all of the frameworks for these--they probably will be available just about everywhere--but a little context about the baseline might help someone.

Yes, you are right about this one. By "Zero Dependency and implemented in Bash" I mean two things:

• apart from a few common tools (e.g. as you mentioned, coreutils and grep), you don't need anything else.
• the source code of the testing framework is Bash (e.g. it's not a single executable binary produced by a C++ project), so a Bash-savvy person can read the source code easily

The first one could be more precise I agree, but I don't really have an idea how to list all the dependencies needed by the tools. This is why I settled on the idea that "Zero dependency" == it only depends on stuff you probably already have. Besides, I think all the frameworks listed are depending on a few tools, so in this sense none of them has "zero dependencies".

I'll add a note about this to the comparison table.

What was your goal when you were searching for a pure bash test framework, that does not depend on coreutils? Did you find one?

At first I interpreted this as meaning the framework itself is pure bash. But, it also depends on coreutils, sed, and grep--so I am guessing that maybe the statement means that the tests are pure bash?

Yes, this is what I intended to mean by this. I'll clarify the wording.

Cheers,
David

from testing-in-bash.

I've updated the main comparison table to include a note about what "Zero Dependency and implemented in Bash" means, and I also corrected the wording about "pure bash" in example-shunit2/readme.md.

from testing-in-bash.

What was your goal when you were searching for a pure bash test framework, that does not depend on coreutils?

I've been working on a CLI tool (resholve) that resolves "bare" references to external commands and rewrites them to absolute paths. (acutely, this meets a need for the Nix package manager to be able to find and explicitly specify external dependencies)

I test it with bats (and am pretty happy with it), but I have a chicken/egg problem: I can technically use resholve to package bats for Nix, but it would create a cyclic dependency between the two Nix packages.

Addressing it is fairly far down my priority list, but I was curious if there was an established pure-bash replacement.

Did you find one?

I didn't (or haven't? :)

from testing-in-bash.

I see, thanks for the input! (Cool tool btw! 👍)

With this I'll close this issue because I see no obvious way forward on how to make the dependency listing more precise.
Hopefully the updated wording resolves the ambiguities.

from testing-in-bash.

There's also a ~related comment in example-shunit2/readme.md:

If you are after a "pure Bash" testing framework, make sure to also check bash_unit.

At first I interpreted this as meaning the framework itself is pure bash. But, it also depends on coreutils, sed, and grep--so I am guessing that maybe the statement means that the tests are pure bash?

from testing-in-bash.