Core: Allow hooks via this.hooks
in nested modules.
#1200
Closed
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.
During review of the new Ember testing RFC (emberjs/rfcs#232) the required
hooks
argument has "raised some eyebrows".To summarize that RFC proposal briefly, I am proposing that we leverage nested modules as the default and stop wrapping QUnit functionality with our own custom APIs.
Roughly, instead of
moduleFor
(which generates aQUnit.module
with the properbeforeEach
/afterEach
callbacks), we leverage nested modules and provide simpler helper functions that setup thebeforeEach
/afterEach
:Some of the concerns raised during that RFC center around the
hook
object:hooks
means is a bit more difficult because it does not represent the "test environment", but rather just the hooks.hooks
to the helper functions proposed in the RFC means that if we ever need to thread more information through, we either have to usehooks
as a transport or change our API to add more arguments.hooks
as a state/transport mechanism).The concerns seemed reasonable, so I figured I'd kick off some discussion here (with a PR adding the functionality that I think would assuage the concerns).
Open questions:
testEnvironment.hooks
to already be present (e.g.module('foo', { hooks: 'fishing' }, function(hooks) {})
)?this.hooks.*
withhooks.*
, etc)?