Testing Interactive Shell Commands Doesn't Work

[ryan-bradford]

I have followed the guide for setting up testing infrastructure as written in the GitHub issues:

1. Suggestion for solving the REPL stuck problem during integration tests #203
2. Integration Testing With Spring-Boot + Spring-Shelll #204

My testing class looks like the following:

@Import(TestShellApplicationRunner.class)
@SpringBootTest(properties = {
    "spring.shell.interactive.enabled=false",
    "config.properties-path=./src/test/resources/client-application-test.properties"
}, classes = TestApplicationClass.class)
class TestCommandCommandTest {

    @Autowired
    private Shell shell;

    @Autowired
    private DefaultResultHandler resultHandler;

    int count = 0;

    @Test
    public void contextLoads() throws Exception {
        assertNotNull(shell);

        Object help = shell.evaluate(() -> "test-command");
        assertNotNull(help);
        System.out.println(help);
    }

}

In the application, I wish to trigger my command "test-command". This command then shows a selector using the SingleItemSelector and asks the user to select from 3 options.

However, in the above setup, "test-command" is correctly triggered, but I cannot find a way to give input for the selector and I am always given a NoSuchElementException (I.E. no user input was received and it did not way for user input).

I've tried many ways:

1. Setting spring.shell.interactive.enabled=true - but then I have no way of interacting at all as other have observed.
2. Using shell.run(....) but this appears to lead to the same problem
3. Attempting to mock the entire JLine framework, but this just led to frustration.

Versions:
Java: openjdk 11.0.16.1
Spring Shell: 2.1.1

[jvalkeal]

I'm going to close this in favour of #489, please follow it.

Short story is that trying to hack into spring-shell internals to do testing like this is way too difficult. We've done some integration tests which are always opinionated for current use case. Also what comes out from a JLine is just meant for a terminal emulation so you need to interpret that as well.

[ryan-bradford]

Yea, that's essentially what we ended up doing and it worked quite well in the end. Thanks for the fast response, and I'll keep and eye on that issue going forward!