-
-
Notifications
You must be signed in to change notification settings - Fork 257
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
Leaking states between tests (because of acceptance tests) #243
Comments
Some somewhat random thoughts:
|
IMO I've also used it for this: For some reason (if you want I can try to find out) I wasn't getting sporadic test failures with the same tests using the old Where does that leave us / what's the recommendation? EDIT |
Hmm, its definitely not the same at all.
Ya, it is worthwhile to figure this out IMHO. My statement before was based on the fact that
If you do need to do this, I would do it in a
Not sure. The biggest issue is that we just need to land the acceptance testing system here ASAP, but for that to work we need to settle the RFC first... |
Then I was mistaken... Probably because I didn't know Another update... |
Using a mix of
nested-module-testing
for integration and unit tests, andmoduleForAcceptance
for acceptance tests:If tests modify the testing container but don't call
teardownRenderingContext
then the state is carried throughout the tests because ofhttps://github.com/emberjs/ember-test-helpers/blob/master/addon-test-support/%40ember/test-helpers/setup-rendering-context.js#L43
I just got bit by an acceptance tests that runs an initializer that modifies the root element https://github.com/yapplabs/ember-modal-dialog/blob/master/addon/initializers/add-modals-container.js#L31
and renderingTests that run after it (and use
find('*')
) break because the first element ismodal-overlays
instead of the component under testIdeas on how to remediate this:
after
hooks, (until we overhaulmoduleForAcceptance
)The text was updated successfully, but these errors were encountered: