One approach could be to have a main() overload taking an additional
Environment argument to abstract access to environment variables, system
properties, and standard I/O; and returning an int as the possible
System.exit() value.
That way, you can easily stub the environment for tests.
Your standar
It depends on the criticality of your command line tools. One
interessting approach is the one by the SpringBoot guys. They run
commands in a Docker container and collect stdout to check the behaviour
of their System V start script.
=>
https://github.com/spring-projects/spring-boot/blob/9d078
Have you considered writing an integration test that invoked your command
line tool from the command line?
When you use tools like Failsafe, JUnit, etc, you can know that the process
works in that environment, but the real world execution won't be the same.
While most of your corner cases, logic,
When writing integration tests for command-line tools, is there any
support in Failsafe, jUnit, or elsewhere to fork a process and manage
its standard IO streams?
Or am I over-designing? Would one typically write such an integration
test rather like a unit test, bypassing the command analyzer and
