Organization of some lib/scripts

[nkakouros]

Due diligence

• I am familiar with the "Reporting issues" section of CONTRIBUTING.md
• I have searched the existing issues and haven't found one that matches what I'm reporting or requesting now.
• If this is a bug report, I have searched the Bash changelog for information that may explain or provide clues to the behavior I'm observing and reference it in the body of the report.

Description

I am not sure I understand correctly the organization of the library files, but I thought I would ask anyway.

Under lib/ there is the bats-main script. This is the entry point to ./go test.
Then, almost each test file loads the tests/environment.bash file.
This, then, loads the "main" environment file lib/testing/environment plus the assertions library lib/bats/assertions.

If I understand the naming correctly, lib/bats/ is for libraries adding functionality that Bats is missing (more or less). So, we have the assertions library and background-process there. Then, lib/testing/ is for files that the test files will load on-demand if they need some special functionality to drive the application, eg the lib/testing/stack-trace file.

If the above are correct, here are my questions:

1. Shouldn't lib/bats/assertion-test-helpers be under lib/testing as it contains special functions to test a part of the application?
2. Shouldn't lib/bats/helpers, lib/bats/helper-function, lib/testing/environment be under a separate 3rd folder named perhaps lib/test-helpers or lib/testing-common or lib/testing/common? My thinking is that what these 3 files have in common (and what distinguishes them among the rest) is that they provide functions to write richer test functions.

This is not a functionally important issue but re-organizing might help a new contributor understand more easily what is going on and what each file is supposed to do. At least so it seems to me after spending ~1 hour trying to find where functions came from and the hierarchy of sourced files.

What do you think?

[mbland]

Fair questions. I do have a small explanation in the README to explain my intent with the current structure: https://github.com/mbland/go-script-bash#bats-test-assertions-and-helpers

Bats test assertions and helpers

The assertions and helpers from the test suite have been extracted into the lib/bats libraries. While these are not modules you can import with _GO_USE_MODULES, they are completely independent of the rest of the core framework and you may source them in your own Bats tests. (Whether or not these will ever become a separate library remains an open question.)

Variables, helper functions, and assertions for testing features based on the core framework are available in the lib/testing directory. The lib/bats-main library makes it easy to write a ./go test command script with the same interface and features as the core framework's ./go test command.

The key thing is that everything in lib/bats depends on nothing from the core framework at all (even though it's all tested with ./go test bats-*). Ideally I'd like to hoist that into a separate library (perhaps as a bats-core project).

Regardless, even within this repository, it might be worthwhile to reorganize the directories, just so long as everything in lib/bats remains completely independent.