Most of the Tools integration tests written in Go manually construct an options argument as it would appear post-parsing.  This has several negative consequences:

• Code in the main function has no test coverage
• Integration tests may reflect an options state not actually achievable via options parsing
• Options configuration in tests is cumbersome for any non-trivial set of arguments
• As a consequence of the two points above: repro tests of user-reported bugs are both hard to write and may not accurately reflect the options state of the reported bug

To fix this, several things need to happen to the Tools and their tests:

• Tools "main" functions should be refactored into thin wrapper that passes os.Args to a (non-main) package Run function that consumes a slice of strings.
  • Run will generally have four parts: (1) constructing an options object from command line arguments, (2) constructing UI elements, (3) constructing/initializing the tool object from options, (3) invoking the tool object.
  • Depending on the tool, this may require pulling late options configuration out of the tool execution function (e.g. Dump) into Run
  • Alternatively, #1 could be combined into #3 – where the tool object is constructed directly from a slice of strings
• For "end-to-end" integration tests that simulate command-line argument invocation (e.g. repro tests), tests must be rewritten to call Run with desired arguments.
• For integration tests targeting specific subsystems, tests must be rewritten to construct an options object from a slice of strings and a corresponding tool object before invoking the subsystem code under test