Sample integration test could use more substance to it

While the sample integration test does a great job of demonstrating how to set up the downloading of VS Code and setting up running the tests within VS Code, the integration test (https://github.com/microsoft/vscode-test/blob/main/sample/test/suite/extension.test.ts) which tests the sample extension (https://github.com/microsoft/vscode-test/blob/main/sample/src/extension.ts) doesn't have much substance to it - it validates that array.indexOf() returns -1, which doesn't really have much to do with validating the extension, and doesn't demonstrate how to drive the UI, and check & validate the state/contents of the UI after the test finished.

It would be very helpful if there were examples demonstrating how to implement integration tests (end-to-end/integration tests, not unit tests), and show how to drive the UI, and test/validate the UI for expected results.

Now, one might say, "it's easy, just..."

1. Add vscode.commands.executeCommand('helloworld.helloWorld') to the test
2. and then write a spy to verify that vscode.window.showInformationMessage() is called, and that it's called with "Hello World!"

This has some shortcomings:

1. Directly calling executeCommand() and passing mocked data (the "rest" parameter) which we mock ourselves is not adequate. We recently found a bug where VS Code passes bad data to commands. (see https://github.com/microsoft/vscode/issues/152993). Microsoft says it's not a bug, but it is for us - when we're passed an incorrect file path, a library we depend on fails, so we wrote code to get around this and we need to write tests which automate this end to end.
   For this reason, we want to issue an instruction to VS Code itself, and tell VS Code to "run the "ABC" command", and not directly call executeCommand()

2. We need to be able to drive the UI, and the driving needs to be performed at a high level - as if the user was typing themselves, and not programmatically by calling APIs or functions directly. Suppose our extension presents the user with a text prompt when the extension's command is invoked, and the user is prompted to enter in a string. We need to be able to write a test which waits for the text input prompt to appear, and then enter/input some text. Now suppose that when the command is invoked, that the user is prompted for input several times (to input several different values). We don't want to stub functions - we have a goal to make our integration tests be end-to-end, and be as if the user was inputing the data themselves, so this means no mocks/stubs.

What we want to do might not be aligned with how you intended integration tests to work, but...

1. if that's the case, it's hard to tell, because the sample test doesn't actually do much and doesn't test the extension
2. it would be helpful if there were several "real world" examples, so we (all VS Code extension developers, not just my team) could see the "best practice" approach to take.

Thanks,

Jeff

Start with sample/test/suite/extension.test.ts and sample/src/extension.ts to understand the current sample integration test and extension behavior. Expand the sample with realistic end-to-end examples that invoke commands through VS Code, drive UI input without mocks or stubs, and validate the resulting UI state and contents.