Open kettanaito opened 6 years ago
Consider rendering scenario anew for each test, instead of relying on interactive methods like this.form.reset
. This can eliminate timeout necessity issue.
window.form
, i.e. accessing internal state and asserting returns of the methods. This won't be integration tests per design, but if this guarantees reliability (as opposed to now), I would go for it. This is also how integration tests were written previously..should($el => ...)
, which may grant more control over re-trying a certain assertionOne of the reasons the current integration tests are not reliable may be related to the side-effects in Field.componentWillReceiveProps
. Having side-effects in that lifecycle method is a no-op, and it can cause unreproducible buggy behavior.
I have removed integration tests from the build pipeline for now. Tests still run on local to ensure nothing is broken. I think Form-Field communication needs to be refined to remove mentioned side-effects, and be more bulletproof. It may be a good opportunity for #232.
The reliability of the CI is highly dependent on the #324.
Environment
What
I suggest to consider the necessity of explicit
cy.wait
in the integration tests.Why
Using timeouts may be suitable in some cases, but I am growing worried that the library responsiveness may be in risk. The reason of using timeouts is (probably) related to the form not being fully bootstrapped before trying to run assertions on it, or its fields.
How
This is also a task to establish a reliable CI pipeline. I hate to see current setup producing falsy negative results during integration tests, this is unacceptable. Need to figure out why this happens, and how to eradicate it at its core.