Closed ivelin closed 4 years ago
@ivelin Have you reviewed the video or screenshots of the failure? Is the element covered when you review these? It may be a situation where if there is some timing differences, the element is not visible within the 4 sec timeout sometimes.
This is failing because the element you are trying to click is sometimes covered by an opacity element. You can see it when you run locally sometimes.
I don't exactly knows what controls whether this opacity element is shown in your app, but you'll want to make sure that that is gone before attempting to click.
Thank you for the investigation. I do see that there is an element covering the button during cypress testing, but the question is why doesn't this ever happen to real users. There is something between the cypress and vuetify interaction that needs to be documented.
It could be some timing issue, but I'd have to dig in to be sure. Cypress clicks and moves faster than regular users most times.
Yes, it feels like Vuetify protects input until the whole page is rendered and buttons are ready to do what they are expected. It is tough to track down because its seamless to the human eye.
I've been battling Cypress and Vuetify in a non-trivial application off and on for months just to implement a simple smoke test so I know if changes made have broken something. Literally one single form with every input control type represented to do a simple create update remove cycle. Tests that work one minute fail the next inexplicably, there is no consistency and many of the Vuetify components are almost untestable such as the datetime selectors etc. One out of 3 runs the tests just fail inexplicably, I keep needing to add more {force:true} parameters everywhere and still failing. I seriously doubt Cypress and Vuetify are a viable combination at all.
@WhatFreshHellIsThis Please open a new issue with a fully reproducible example, we'd be happy to take a look at the issue.
Unfortunately there are just too many issues and I don't have the time at the moment; I really do think it's likely a lost cause, they just likely can't be compatible in any stable way due to the highly dynamic nature of Vue/Vuetify, the constant dom rewriting and the sheer number of changes that would need to be made to components to have a stable way to hook into them from Cypress. I've already made a case for making the components more testable on the Vuetify side of things some time ago but I'm really doubting there would be any stable common ground possible between the two projects.
Thank you for your response. It is unfortunate that two great frontend tools like Vue(Vuetify) and Cypress can't come to common ground. Hope the teams reconcile in the near future. There is an open related issue in the Vuetify repo: vuetifyjs/vuetify/issues/11436
I'm using protractor as a framework and I faced the same problem. The way that I found was to wait till all transitions ends. In order to identify when a transition is active is looking for elements with that classes (.dialog-transition-enter-active or .dialog-transition-leave-active), so when these elements have been vanished, we can say that the transition has ended.
My solution looks like:
await browser.wait(
EC.and(
EC.stalenessOf($(".dialog-transition-enter-active"),
EC.stalenessOf($(".dialog-transition-leave-active"))
)
),
timeout
);
I'm having the same issue. It's the inconsistency kills. This is a bad user experience and have no solution for it.
Current behavior:
The following cypress e2e tests should pass always, but sometimes fail. https://github.com/ambianic/ambianic-ui/blob/77e5b54ea12cacf6695f2edc629dea9601a43992/cypress/integration/ambianic-tests/about.spec.js
The error is the same on my local environment and github action script:
Desired behavior:
These tests should always pass.
Test code to reproduce
Source of test provided about. All app source code is on a this public repo branch.
Versions
Cypress 4.3.0 , Chrome, Ubuntu