main.go lacks sufficient unit test coverage

[jnd-au]

Currently, unit-test coverage of main.go is limited because of operating system blockers like os.Exit. It would be good to have a workaround so that main.go can be tested, as tz now supports a variety of combined options and configuration features that need to be coded carefully. Possible options:

1. Run nested ./tz as a separate process within unit tests.
   • Pro: Simple, conventional coding pattern.
   • Con: Won’t show code-coverage statistics, so we don’t know how good the testing is.
   • Con: Need to be careful about isolating tests from local variations in the OS runtime environment.
   • Con: Complexity of testing of error-handling code paths that require misconfigured OS environments.
2. Refactor main.go to use more abstractions (e.g. don’t use bubbletea directly, use FlagSet instead of flag, etc).
   • Pro: A clean approach that is very test-friendly.
   • Con: Design of main.go becomes unconventional and bespoke.
   • Con: Lots of functions and lines will need large changes.
3. In main_test.go, invoke the main method multiple times but intercept exits, panics, and stderr/stdout.
   • Pro: No changes to main.go.
   • Con: A bit complex / impossible to intercept some terminations like os.Exit etc.
   • Con: Golang standard libraries (e.g. flag) are designed contrary to this.
4. Compromise between Option 2 and Option 3 by doing the minimal amount of Option 2 to support Option 3.