-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Add keystrokeDelay
configuration option
#566
Comments
This would be convenient to configure globally.
But in a real world with real users, that is how the app will actually behave, right? So why should it behave differently under the test? |
@sompylasar The way I'd answer that is that we sometimes take the trade-off of not testing a 100% accurate user experience if the benefit is faster test execution. We're already making some of these trade-offs already. For example, a user doesn't click a button immediately after a page loads; they would likely take some time reading text or scanning the UI and deciding their next course of action. But with end-to-end tests, we're doing all kinds of things super fast because mimicking the time it takes to read text and scan the UI is not worth the cost. Of course, simulating a regular typing speed is super important in some cases, so it's nice to have the flexibility. |
At least there's a way to simulate that with a wait if the UI under test is time-sensitive.
It's too bold of a decision for the authors of a test framework (Cypress) to estimate the cost for each use case that they might not know about. Provide a good API and good defaults, okay, but let the users make decisions. |
This would be helpful but maybe another way to accomplish this is by adding a secondary method that will fill out a field without delay and leave the "type" method intact as is. This way, if you want to "type" into an input it works as expected. If you just want to fill the input you do something like
or something? |
The suggestion for |
Seriously need this feature. Those ci build minutes are expensive. |
Here's one custom command I've been using in the interim. If you're app sets up form input event listener's on either // in your commands file:
Cypress.Commands.add('fill', {
prevSubject: 'element'
}, (subject, value) => {
cy.wrap(subject).invoke('val', value).trigger('input').trigger('change')
});
// Usage in spec:
cy.get('[data-my-input-field]').fill('Hello'); |
Having issues with this when dealing with Formik. I tried adding the events |
The problem with this solution is not having all necessary events triggered. I'm using This feature is really important when you have to add a long text into a textarea... @brian-mann any plans on working on this feature any time soon? |
@scaryguy haven't found a workaround. I reduced the typing delay to its minimum, but my tests involve breaking string max boundaries (sometimes 255 char...) so an actual implementation of this feature would be much appreciated, I'd probably reduce the time of runs by 60% |
It seems that reducing the delay with cy.type("hello", {delay: 1}) doesn't do anything if you try to go below 10ms. |
I'm not saying this is ideal, however I've managed to finally get this working with React 16.8 with a Cypress.Commands.add('fill', {
prevSubject: 'element',
}, ($subject, value) => {
const el = $subject[0];
el.value = value;
return cy.wrap($subject).type('t{backspace}');
}); Since |
This might be not much of a difference, but still I like it more: Cypress.Commands.add('fill', { prevSubject: 'element' }, ($subj, text) => {
$subj.val(text);
return cy.wrap($subj).type('{end}');
}); |
Thanks. Works perfectly. We need an official solution though... |
Any updates on this? |
None of these solutions worked for me, so I created a npm package that is working on React with Material-UI in the lastest version: I used some info collected from all related posts, so, if you feel that you need to be tagged on it to give properly credit, contact me. |
Takes a regular expression?.. :) |
Ops, my mistake in the docs, it should only receive a simple string as a parameter. Already fix it. |
Works perfectly. Thanks |
Instead of adding a random 't' and a backspace keypress, why not just split off the last character, and type it into the input? Cypress.Commands.add('fill', {
prevSubject: 'element',
}, ($subject, value) => {
const el = $subject[0];
el.value = value.substring(0, value.length - 1);
var lastChar = value.substring(value.length - 1, value.length);
return cy.wrap($subject).type(lastChar);
}); |
Probably because with UPD Okay, I jumped to conclusions. I somehow thought that with |
The code for this is done in cypress-io/cypress#15683, but has yet to be released. |
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Currently Cypress uses a
setTimeout
between keystrokes to mimic how a user would press each key.Concern 1:
We should enable this property to be globally configurable such as
keystrokeDelay
.Concern 2:
When set to
false
or0
, instead of making each key press be async, we should make it synchronous. This would be helpful to not only type faster but could make things easier for 3rd party JS frameworks such as react.Currently as it stands since keypresses as async - its indeterminate whether or not your JS framework has finished 'processing' all of the keystrokes. For instance it may fire its change events while typing vs after all characters have been typed. See issue #534 for more detail.
Concern 3:
When typing very long sequences its often useful just to have it all "type at once" and not have to wait. Give developers the choice to decide.
Recommendation
keystrokeDelay
totrue
by default (which is the minimumsetImmediate
async between key presses)keystrokeDelay
is set tofalse
or0
typing all characters synchronouslykeystrokeDelay
is set to a number then use this as thesetTimeout
valuePassing the
delay
option tocy.type()
will override anything globally set in config.The text was updated successfully, but these errors were encountered: