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:
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.
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.
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.
Compromise between Option 2 and Option 3 by doing the minimal amount of Option 2 to support Option 3.
Currently, unit-test coverage of
main.gois limited because of operating system blockers likeos.Exit. It would be good to have a workaround so thatmain.gocan be tested, astznow supports a variety of combined options and configuration features that need to be coded carefully. Possible options:./tzas a separate process within unit tests.main.goto use more abstractions (e.g. don’t usebubbleteadirectly, useFlagSetinstead offlag, etc).main.gobecomes unconventional and bespoke.main_test.go, invoke themainmethod multiple times but intercept exits, panics, and stderr/stdout.main.go.flag) are designed contrary to this.