Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Documentation #19
Documentation #19
Changes from 5 commits
4287ad3
81b5b74
6d49c18
eb85616
a10f646
e12a23d
27958ef
73842a8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you say something about what
milestones
addresses that is not covered by the Ember built-ins explained here?https://guides.emberjs.com/release/testing/acceptance/
Maybe the reader can deduce from the Core docs, but I think it would help to be more explicit.
The official Ember docs imply, perhaps unintentionally, that the ember test helpers already provide all you need to test asynchronous code.
In a few Salsify projects we've used milestones heavily, but since it's not (yet) a widely used package, I've wondered how other teams tackle these problems. A mocking library like
sinon
? Simply not writing certain kinds of tests?A couple sentences, or maybe a before/after example as in the
ember-concurrency
docs, could clarify when it's the right tool.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great point. I had a bit written up about this (and it was also the bulk of the content in the mini-talk I gave at the Boston meetup last fall), but it got lost in the shuffle as I was writing everything else up.
I'll re-integrate that into the Ember page on the site (my goal is to keep these READMEs as lightweight as possible and push people toward the richer interactive site), and I'll also try and add a bit of more general-purpose motivation to the core docs as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Broadly speaking I think people tend to go one of three ways, depending on their personal priorities:
sleep
s throughout code to always ensure you've settled in the right state, but accept that your test suite will be slowI've done all of those at different points in the past, at Salsify and elsewhere, in codebases with and without Ember. My general experience is that projects tend to be in a constant state of flux between those different tradeoffs, depending on the values of the person who most recently 'fixed' the test suite.