Archive the non-ported remainder of the legacy KNELServerBuild repo
under archive/KNELServerBuild/ with its original structure intact,
completing the legacy repo merge for everything except the live
LibreNMS patterns (ported in the previous commit).
Exclusions:
- .git history (superseded; legacy repo remains at its original path)
- ported files (Agents/librenms, Modules/OAM/oam-librenms.sh,
ConfigFiles/SNMP/snmp-sudo.conf)
- vendored KNELShellFramework tree (byte-identical duplicate of the
copy already vendored at vendor/ in this repo)
- SSH authorized-keys files (live access-control material; carrying
them in an archive invites drift — key policy lives elsewhere)
The whole tree is skip-listed in tests/shellcheck.sh (archived legacy
code, not maintained — same standing as vendor/); check-rules.sh
already prunes archive/. Rule 9 (conflict markers) now also excludes
archive/ staged files: preserved-verbatim legacy scripts contain
decorative "====" banners that false-positive as conflict markers
(same archive exclusion precedent as rule 11).
AGENTS.md: note archive/KNELServerBuild and oam/librenms-agent in the
Repository Layout, and fix the stale KNELIAC path to
/home/reachableceo/projects/KNEL/KNELIAC.
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
5.0 KiB
5.0 KiB
TSYS FetchApply Testing Framework
Overview
This testing framework provides comprehensive validation for the TSYS FetchApply infrastructure provisioning system. It includes unit tests, integration tests, security tests, and system validation.
Test Categories
1. Unit Tests (unit/)
- Purpose: Test individual framework functions and components
- Scope: Framework includes, helper functions, syntax validation
- Example:
framework-functions.sh- Tests logging, pretty print, and error handling functions
2. Integration Tests (integration/)
- Purpose: Test complete workflows and module interactions
- Scope: End-to-end deployment scenarios, module integration
- Future: Module interaction testing, deployment workflow validation
3. Security Tests (security/)
- Purpose: Validate security configurations and practices
- Scope: HTTPS enforcement, deployment security, SSH hardening
- Example:
https-enforcement.sh- Validates all URLs use HTTPS
4. Validation Tests (validation/)
- Purpose: System compatibility and pre-flight checks
- Scope: System requirements, network connectivity, permissions
- Example:
system-requirements.sh- Validates minimum system requirements
Usage
Run All Tests
./Project-Tests/run-tests.sh
Run Specific Test Categories
./Project-Tests/run-tests.sh unit # Unit tests only
./Project-Tests/run-tests.sh integration # Integration tests only
./Project-Tests/run-tests.sh security # Security tests only
./Project-Tests/run-tests.sh validation # Validation tests only
Run Individual Tests
./Project-Tests/validation/system-requirements.sh
./Project-Tests/security/https-enforcement.sh
./Project-Tests/unit/framework-functions.sh
Test Results
- Console Output: Real-time test results with color-coded status
- JSON Reports: Detailed test reports saved to
logs/tests/ - Exit Codes: 0 for success, 1 for failures
Configuration Validation
The validation framework performs pre-flight checks to ensure system compatibility:
System Requirements
- Memory: Minimum 2GB RAM
- Disk Space: Minimum 10GB available
- OS Compatibility: Ubuntu/Debian (tested), others (may work)
Network Connectivity
- Tests connection to required download sources
- Validates HTTPS endpoints are accessible
- Checks for firewall/proxy issues
Command Dependencies
- Verifies required tools are installed (
curl,wget,git,systemctl,apt-get) - Checks for proper versions where applicable
Permissions
- Validates write access to system directories
- Checks for required administrative privileges
Adding New Tests
Test File Structure
#!/bin/bash
set -euo pipefail
function test_something() {
echo "🔍 Testing something..."
if [[ condition ]]; then
echo "✅ Test passed"
return 0
else
echo "❌ Test failed"
return 1
fi
}
function main() {
echo "🧪 Running Test Suite Name"
echo "=========================="
local total_failures=0
test_something || ((total_failures++))
echo "=========================="
if [[ $total_failures -eq 0 ]]; then
echo "✅ All tests passed"
exit 0
else
echo "❌ $total_failures tests failed"
exit 1
fi
}
if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
main "$@"
fi
Test Categories Guidelines
- Unit Tests: Focus on individual functions, fast execution
- Integration Tests: Test module interactions, longer execution
- Security Tests: Validate security configurations
- Validation Tests: Pre-flight system checks
Continuous Integration
The testing framework is designed to integrate with CI/CD pipelines:
# Example CI script
./Project-Tests/run-tests.sh all
test_exit_code=$?
if [[ $test_exit_code -eq 0 ]]; then
echo "All tests passed - deployment approved"
else
echo "Tests failed - deployment blocked"
exit 1
fi
Test Development Best Practices
- Clear Test Names: Use descriptive function names
- Proper Exit Codes: Return 0 for success, 1 for failure
- Informative Output: Use emoji and clear messages
- Timeout Protection: Use timeout for network operations
- Cleanup: Remove temporary files and resources
- Error Handling: Use
set -euo pipefailfor strict error handling
Troubleshooting
Common Issues
- Permission Denied: Run tests with appropriate privileges
- Network Timeouts: Check firewall and proxy settings
- Missing Dependencies: Install required tools before testing
- Script Errors: Validate syntax with
bash -n script.sh
Debug Mode
# Enable debug output
export DEBUG=1
./Project-Tests/run-tests.sh
Contributing
When adding new functionality to FetchApply:
- Add corresponding tests in appropriate category
- Run full test suite before committing
- Update documentation for new test cases
- Ensure tests pass in clean environment