-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to write unit tests around Prompts #40
Comments
Hi @seancarroll! That's right, I managed to write a few tests and actually planned to expose this API sometime in the future, but the reason I didn't until now was because it still makes tests very dependent on the current implementation. Each prompt handles almost raw key events as opposed to "commands" (e.g. handles Key::DownArrow instead of Command::MoveDown). Back then I was still planning to improve this part, allowing this custom backend to re-map any desirable key bindings. I am totally okay in prioritizing this next development for you, as I don't have any other major plans for this project at the moment. But to be really honest, I'll start a new job abroad in 1 month and I'm reserving this time I have left here to enjoy my family, so I'm not sure how much I'll be able to contribute for now. If you're interested, we can discuss more this direction and I'd be very happy to accept contributions! |
We can also consider exposing the current method as-is in an alpha release or something, it if makes your life easier sooner :) |
@mikaelmello this isn't an immediate need for me so happy to discuss direction and options. Given you mentioned "commands" I started some very preliminary research and stumbled up enigo which they say is a cross platform input simulation in Rust. Perhaps this is a direction worth looking into? |
@seancarroll that is an awesome find and it would be a great addition for E2E tests in the future, but for unit tests I was thinking about something else, which I honestly don't know if it is indeed better. For context, each The current problem (at least for me) is that key binding definitions are made very deep in the code, not clear from a first glance. This is a problem for users in general (what if we break the API without noticing) and for tests that shouldn't have to worry at this low level of implementation. I was wondering if it was worth for each prompt to have something like: pub enum MultiSelectCommand {
MoveUp,
MoveDown,
ToggleSelection,
...
}
impl From<Key> for MultiSelectCommand { ... } IMO, we have the following pros and cons: Pros:
Cons:
Finally, I believe we should also add E2E tests to ensure we don't break our lib's external API, and enigo looks like the path forward. |
@mikaelmello, thanks for the explanation and insights. |
I want to improve this crate's testability for both the crate and its users. I have created #71 to track the developments on this part. |
Is your feature request related to a problem? Please describe.
I just started to play around with this as part of a CLI i'm building and was curious what suggestions you had for being able to unit test logic that contained inquire prompts? I see that internally you use
prompt_with_backend
Describe the solution you'd like
I would like to be able to add unit tests around code that uses inquire prompts. One possible solution would be to expose
prompt_with_backend
Describe alternatives you've considered
Not sure about alternatives but would love to hear your suggestions
Additional context
The text was updated successfully, but these errors were encountered: