ShellInputProvider inputs are not consumed by `ComponentFlow`-based interactive components (e.g. `ConfirmationInput`, `StringInput`)

[Tountoun]

When a command runs a ComponentFlow with two sequential steps and the test supplies two queued inputs via ShellInputProvider.Builder#withInput(String), the flow throws a NoSuchElementException on the second step's context key — regardless of the value supplied (tested with "y", "yes", "true").

Steps to reproduce

Command under test:

```java
@component
public class ExampleCommand {

private final ComponentFlow.Builder builder;

public ExampleCommand(ComponentFlow.Builder builder) {
    this.builder = builder;
}

@Command(name = "example")
public String example() {
    ComponentFlow flow = builder.clone().reset()
        .withStringInput("reason")
            .name("Reason:")
            .and()
        .withConfirmationInput("confirm")
            .name("Confirm?")
            .and()
        .build();

    ComponentFlow.ComponentFlowResult result = flow.run();
    boolean confirmed = result.getContext().get("confirm");
    return confirmed ? "Confirmed" : "Cancelled";
}

}
```

Test:

```java
@ShellTest
@ContextConfiguration(classes = ExampleApplication.class)
class ExampleCommandTest {

@Test
void testExample(@Autowired ShellTestClient client) throws Exception {
    ShellInputProvider provider = ShellInputProvider.providerFor("example")
        .withInput("some reason")
        .withInput("true")
        .build();

    ShellScreen screen = client.sendCommand(provider);

    ShellAssertions.assertThat(screen).containsText("Confirmed");
}

}
```

Expected behavior

The queued inputs are consumed sequentially by the ComponentFlow steps, and the flow completes with confirm = true.

Actual behavior

```
java.util.NoSuchElementException: Context does not contain key: confirm
at org.springframework.shell.jline.tui.component.context.BaseComponentContext.get(BaseComponentContext.java:44)
at ExampleCommand.example(ExampleCommand.java:...)
...
```

The exception is identical regardless of the value queued via withInput(...) (tried "y", "yes", "true"), which suggests the input is never reaching the ComponentFlow/ConfirmationInput reading mechanism at all, rather than being rejected as an invalid value.

Is ComponentFlow end-to-end testing currently expected to be unsupported in 4.0.3, or is there a recommended workaround I'm missing?

[czpilar]

Thanks for the detailed report - the reproducer made this easy to track down.

Your diagnosis is right: the input never reaches the component. But it isn't a defect in withInput(...); the two pieces are simply not connected. I have worked on that class, so let me explain the scope it was built for.

Why the inputs don't arrive

There are two independent input mechanisms in 4.0:

1. InputReader (spring-shell-core) - what commandContext.inputReader().readInput() uses. ShellTestClient.sendCommand(ShellInputProvider) builds an anonymous InputReader backed by your queues and passes it into the CommandContext. There is no terminal involved at all: output is collected into a StringWriter and the command is invoked directly.

2. The TUI components (spring-shell-jline) - ComponentFlow, StringInput, ConfirmationInput etc. drive TerminalUI and read raw keystrokes from a JLine Terminal. The identifier InputReader does not appear anywhere under org.springframework.shell.jline.tui.

So the queue filled by ShellInputProvider has no path to ConfirmationInput. ShellInputProvider was added specifically for the inputReader() case documented in the testing docs - it was never wired to the component subsystem.

Why it surfaces as NoSuchElementException

The component runs, gets nothing, and finishes with a null result value. The flow's post-run handler only stores the key when a value is present - in ComponentFlow, for the confirmation input:

if (input.isStoreResult()) {
    selector.addPostRunHandler(c -> {
        if (c.getResultValue() != null) {
            c.put(input.getId(), c.getResultValue());
        }
    });
}

That is why the failure is identical for "y", "yes" and "true" - the value is never validated, and the key is simply absent from the context.

One more thing worth noting about your setup: @ShellTest only imports ShellTestClientAutoConfiguration, so neither ComponentFlowAutoConfiguration nor the JLine auto-configuration is part of that slice. You most likely get a ComponentFlow.Builder because your ExampleApplication is a @SpringBootApplication, which pulls full auto-configuration back in - and the resulting Terminal reads from a System.in that is not a TTY under the build runner.

Is this expected in 4.0.x?

Effectively yes, though it is a capability gap rather than a deliberate design statement. Driving TUI components from a test used to be possible through the PTY-based test client, which was removed in a8b05df ("Redesign test utilities", resolving #1234 and #1225) - that commit dropped the jediterm fork, ShellWriteSequence / JLineShellWriteSequence, and shrank ShellTestClient by ~374 lines. Writing raw keystrokes into an emulated terminal was the only way to exercise ComponentFlow end to end, and nothing replaced it.

Workaround

The machinery still exists, but it is test-scoped inside spring-shell-jline and not published as API. See AbstractShellTests and ComponentFlowTests under org.springframework.shell.jline.tui.component.flow in the test sources. The pattern is:

• build a DumbTerminal over a connected PipedInputStream / PipedOutputStream pair;
• build the ComponentFlow yourself with .terminal(dumbTerminal) instead of going through ShellTestClient;
• run flow.run() on an ExecutorService, write the keystrokes into the pipe, and use Awaitility to wait for the result.

Copying that base class into your own test sources should unblock you today.

Possible directions

For the maintainers to decide, roughly in increasing order of cost:

1. Documentation only - state in testing.adoc that ShellInputProvider covers inputReader() and not the TUI components, and show the DumbTerminal recipe.
2. Publish the harness - promote the DumbTerminal setup from test scope into spring-shell-test as supported API, so component flows can be tested without copy-pasting internals.
3. Bridge the two layers - let the components fall back to CommandContext.inputReader() when the terminal is not interactive. Nicest from a user's point of view, but a change to production code in the JLine module.

@fmbenhassine which of these directions would you prefer? I'm happy to open a PR for whichever one you pick.