Improve environment/Bootstrap/Shell architecture to facilitate setup of testing environment

[dkebler]

As you will read below I have a workaround for setup of my module system before testing so this is a non-blocking issue for me for adoption.

BUT.....I did a bit of digging into bashunit and have some suggestions for improvement to make it more flexible to what a dev might need in the way of setup/environment/shell. In general one likes a "clean" environment/shell to do testing but the "ecosystem" might be critical to doing testing.

You can have the "sensible" default be "isolation" (i.e. new non-interactive, non-login shell with clean environment) but allowing flexibility would be again beneficial to adoption.

13. Bootstrap and Environment Issues

Status: Working solution implemented, but bashunit limitations identified

The Problem

Bashunit creates a clean, non-interactive shell for test execution. This causes issues for ucisms because:

1. Non-interactive shell = ucisms not auto-loaded (only happens in interactive shells via .bashrc)
2. Bootstrap file cannot receive arguments = Cannot tell bootstrap which module to test
3. Tests run in subshells = Need proper export of functions/variables

How Bashunit Bootstrap Works

From source code analysis (src/main.sh lines 135-153):

# Optional bootstrap
# shellcheck disable=SC1090
[[ -f "${BASHUNIT_BOOTSTRAP:-}" ]] && source "$BASHUNIT_BOOTSTRAP"

# Then later, tests execute
set +euo pipefail
bashunit::main::exec_tests "$filter" "${args[@]}"

From src/runner.sh lines 389-418:

# Each test function runs in a subshell:
(
 # Run set_up
 bashunit::runner::run_set_up "$test_file"
 
 # Apply shell mode setting
 if bashunit::env::is_strict_mode_enabled; then
 set -euo pipefail
 else
 set +euo pipefail
 fi
 
 "$fn_name" "$@" 2>&1 # ← Test runs here
)

Key Findings:

1. Bootstrap sourced ONCE in main bashunit shell (line 142)
2. Bootstrap runs BEFORE any test execution
3. Tests run in subshells - each isolated
4. Only exported variables/functions available to test subshells

Current Working Solution

Use environment variable to pass module name:

# In testing.mod:
export TESTING_MODULE=$module 
bashunit test "$test_location" --env $bootstrap_file

# In test-bootstrap.sh:
#!/usr/bin/env bash

# Source ucisms (handles non-interactive shell)
if command -v ucisms &>/dev/null; then
 source ucisms
 
 # Load the module being tested
 module_load -r $TESTING_MODULE
else
 echo "[ERROR] ucisms not found in PATH" >&2
 exit 1
fi

Why this works:

• Environment variables ($TESTING_MODULE) persist to subshells
• module_load exports functions making them available to tests
• Bootstrap runs once, making module available to all tests

What Works

✅ Environment variables exported before bashunit runs
✅ source ucisms in bootstrap (ucisms in PATH)
✅ module_load -r $MODULE loads module fresh
✅ Exported functions available in test subshells
✅ setup() and teardown() hooks work correctly

What Doesn't Work

❌ Bootstrap file cannot receive arguments
❌ Cannot pass module name directly to bootstrap
❌ No option to inherit current shell environment
❌ Functions defined in bootstrap without export aren't visible

Recommendations for Bashunit

ISSUE #1: Bootstrap Argument Passing

Bootstrap file cannot receive arguments. Suggest one of:

Option A: Shell-style argument passing

# Current limitation:
bashunit test --env bootstrap.sh tests/

# Desired (like bash -c):
bashunit test --env "bootstrap.sh logger" tests/

Option B: Separate flag for bootstrap arguments

bashunit test --env bootstrap.sh --env-args "logger" tests/

Rationale:

• Common pattern: bootstrap needs to know what's being tested
• Avoids global environment variable workaround
• More explicit and testable

ISSUE #2: Environment Inheritance Option

Provide flag to inherit current shell environment:

# Similar to sudo -E (preserve environment):
bashunit test --preserve-env tests/

# OR
bashunit test --inherit-environment tests/

Rationale:

• Some tests want clean environment (current behavior)
• Some tests want to test in current context
• User should choose (like sudo -E does)

ISSUE #3: Login Shell Option

Provide flag to run tests in a login shell:

# Run tests in login shell (sources profile, etc.):
bashunit test --login tests/

# OR
bashunit test -l tests/

Rationale:

• Login shells source /etc/profile, ~/.bash_profile, etc.
• Some environments/tools only available in login shells
• Developers may want to test with their full login environment
• Not necessary for ucisms (uses non-interactive sourcing)
• Useful for testing user profile configurations

ISSUE #4: Documentation Clarity

Document that:

1. Bootstrap runs in main shell ONCE (not per-test)
2. Tests run in isolated subshells
3. Only exported variables/functions visible to tests
4. Use export for cross-test availability
5. Tests run in non-interactive, non-login shell by default

Rationale:

• Common source of confusion
• Not obvious from current docs
• Helps users understand bootstrap scope
• Explains why profile scripts don't run

Current Status

✅ WORKING - Environment variable solution is functional

Limitations accepted:

• Must use $TESTING_MODULE environment variable
• Cannot pass arguments directly to bootstrap
• Requires explicit export of functions/variables

Next Actions:

• File GitHub issue 1: Bootstrap argument passing
• File GitHub issue 2: Environment inheritance option
• File GitHub issue 3: Login shell option
• File GitHub issue 4: Documentation improvements
• Document ucisms bootstrap pattern in testing docs

---