Implementing basic integration testing using Enigo

[BlackPhlox]

First draft to implement unit test as referenced in issue #95.
Since now that dialoguer has gotten a CI setup, might be worth the effort.
In order to make integration testing for dialoguer, we have to use a cross-platform input simulation library, the only crate which is capable of this is Enigo. The initial draft has some caveats which are worth reviewing/addressing prior to any merging.

Caveats:

(Not relevant)

• Having to extend the API in order to inject keypress simulation.
• Having to check for initiation of the prompt to prevent an endless loop.
• Having to use &mut self (prev &self) as the argument on interact (Already made this for input.rs from Allow FnMut for validate #96).
• Linux Wayland is not supported by Enigo yet.
• CI Build might fail on Linux if libxdo-dev is not installed (Library for simulating X11 keyboard/mouse input).

Result:

C:\...\dialoguer>cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.76s
     Running target\debug\deps\dialoguer-96ea80d1773ee7b6.exe

running 3 tests
test prompts::select::tests::test_ref_str ... ok
test prompts::select::tests::test_string ... ok
test prompts::select::tests::test_str ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target\debug\deps\select-46165e106123627c.exe

running 1 test
✔ Optionally pick your flavor · Vanilla Cupcake
test basic_navigation_produces_correct_selection ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests dialoguer

running 17 tests
test src\prompts\input.rs - prompts::input::Input::validate_with (line 128) ... ok
test src\prompts\input.rs - prompts::input::Input (line 32) ... ok
test src\prompts\confirm.rs - prompts::confirm::Confirm::with_theme (line 45) ... ok
test src\prompts\confirm.rs - prompts::confirm::Confirm (line 11) ... ok
test src\prompts\confirm.rs - prompts::confirm::Confirm::interact_on (line 128) ... ok
test src\prompts\multi_select.rs - prompts::multi_select::MultiSelect (line 10) ... ok
test src\prompts\input.rs - prompts::input::Input (line 18) ... ok
test src\edit.rs - edit::Editor (line 13) ... ok
test src\prompts\select.rs - prompts::select::Select (line 14) ... ok
test src\prompts\select.rs - prompts::select::Select::interact_on (line 206) ... ok
test src\prompts\password.rs - prompts::password::Password (line 12) ... ok
test src\prompts\select.rs - prompts::select::Select::interact_on_opt (line 229) ... ok
test src\prompts\select.rs - prompts::select::Select::with_prompt (line 162) ... ok
test src\prompts\select.rs - prompts::select::Select::item (line 115) ... ok
test src\prompts\select.rs - prompts::select::Select::items (line 135) ... ok
test src\prompts\select.rs - prompts::select::Select::with_theme (line 61) ... ok
test src\prompts\sort.rs - prompts::sort::Sort (line 12) ... ok

test result: ok. 17 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

[pksunkara]

Do we need this fn?

[BlackPhlox]

I might be able to avoid it if I modify and create a custom Term. However, I can promise you it won't be pretty and goes against basic design principles. I agree that we should minimize any fn's that does not benefit the user. So it might be an idea to find an use-case for it?

[pksunkara]

Could you please explain a bit on why exactly does enigo stuff need to happen after rendering the prompt and not before the whole interact fn?

[BlackPhlox]

It doesn't and I think it should be prior to any rendering. I just did it as a test for the sake of getting visual feedback.

[pksunkara]

In that case, we don't need this function. Please setup enigo before calling interact in the test.

[BlackPhlox]

Done.
Next step is:

• We have some test in bottom of prompts/select.rs, do we want that to stay or should it also be moved to tests/select.rs?
• Configure CI so that the integration test passes

[pksunkara]

Those are unit tests. We don't want to move them to tests folder.

[BlackPhlox]

Got it, I've renamed the pr to integration test (based on this).
Regarding CI, we currently use cargo test --lib. We have to use cargo test --tests to also accommodate the integration tests. Seen as I don't have the rights to cancel a workflow, I would rather have you monitoring the workflow with the changes. As it previously created an infinite loop when calling the 'before' fn after the rendering step, but it might still do it (It only happens in the workflow).

Either way, this doesn't have to be rushed by any means, especially given the date, Happy New Year Pavan! 🎆

[BlackPhlox]

@pksunkara Even though it doesn't create an endless loop locally, it does on the CI, please cancel this workflow: https://github.com/mitsuhiko/dialoguer/actions/runs/452562230/workflow

[pksunkara]

Happy new year to you too. Instead of me monitoring the workflow, you can try to get the CI working in a different branch after enabling github actions for your fork. I think that's a good way to test the CI before updating the PR.

[pksunkara]

Is this ready to be reviewed? I didn't get any notification from this PR after my last comment?

[BlackPhlox]

Sorry, have been busy with work. It works locally. However, the integration test sticks in an endless loop when run via CI. I believe this is either a but or a limitation of console which dialoguer is built on top of. You can replicate this issue locally if you use a terminal that hooks into another terminal and runs the program, for example, IntelliJ's in-program terminal has the same issue. I might create an issue over at the console repo. Right now I don't the time nor do I have access to IntelliJ programs as my license has expired.

[pksunkara]

Then why do I see green here?

…

On Wed, Jan 27, 2021, 17:11 Mikkel Rasmussen ***@***.***> wrote: Sorry, have been busy with work. It works locally. However, the integration test sticks in an endless loop when run via CI. I believe this is either a but or a limitation of console <https://github.com/mitsuhiko/console> which dialoguer is built on top of. You can replicate this issue locally if you use a terminal that hooks into another terminal and runs the program, for example, IntelliJ's in-program terminal has the same issue. I might create an issue over at the console repo. Right now I don't the time nor do I have access to IntelliJ programs as my license has expired. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABKU35IQJGQ3WRKOBYQ543S4BCKLANCNFSM4VNU5QWQ> .

[BlackPhlox]

Because current yaml does not include running the integration test when triggered. So technically you can merge this pr without issues, its just that if you change cargo test --lib to cargo test --tests in the yaml the CI will never end and just keep running indefinitely. Though local integration test is possible.

[bew]

Hello @BlackPhlox, I don't understand why you took a graphical input simulation lib for this..
dialoguer is (as far as I know) a terminal helper crate, it doesn't have anything to do with graphics like X11/Wayland nor does it has to deal with cross-platform input systems.

Terminal programs are pretty simple to test in general because the interface to interact with them is universally known and is based on stream of keys and other escape sequences.

To me enigo is the wrong tool for the job here, you don't need this, you don't need the complexity of GUI stuff to test a terminal tool.

To do this right @mitsuhiko, I think that the underlying crate console that is used should be initialized with a dummy/virtual terminal that you can interact with programatically for your tests (to send keys).