Repository navigation
Review API for inject now that we have app modules #9975
Description
In #9846, we switched to using AppModules for tests. This is great because it allows for more flexibility, but one consequence is that each test case may require asynchronous setup, in order to precompile components with external templates (because they need to make an XHR).
The solution in #9846 was to make the inject helper method inspect whether it is being called inside an async block or not. This will work for most current user cases, but destroys encapsulation and ties users to our ways of dealing with async. It's also a lot of 'just trust us magic'.
We could, instead, require the user to let us know if they need to do something asynchronous. This could look like:
beforeEach(async(() => {
configureModule({
precompile: MyComponentWithExternalTemplate;
});
doAsyncPrecompilation(); // Proposed new method
}));
it('does something with that module', inject([TestComponentBuilder], (builder) => {
// This will always be called synchronously now.
var fixture = builder.createSync(MyComponentWithExternalTemplate);
});Currently, (in master at the moment) this would look like:
beforeEach(() => {
configureModule({
precompile: MyComponentWithExternalTemplate;
});
});
it('does something with that module', async(inject([TestComponentBuilder], (builder) => {
// This will throw an error if it's not inside an async block.
var fixture = builder.createSync(MyComponentWithExternalTemplate);
}));Reacted by Suguru Inatomi
Activity
juliemr commentedon Jul 11, 2016
(Also, I'm very happy to hear other ideas to keep things nicely encapsulated but low-boilerplate. I don't love my solution here)
juliemr commentedon Jul 11, 2016
We have one vote for sticking with the status quo: "Of the three evils, this is most magical but least intrusive. I guess I like it best ... Because being explicit gives me more to do and more to explain and I probably still don't know why I'm doing it really unless I'm thinking hard and re-re-re-reading the docs."
juliemr commentedon Jul 12, 2016
Discussed this off thread, and the conclusion is - I'm going to prepare a PR which introduces a function for the user to call which will set up the
AppModuleFactory. This will add some burden for the user to understand when that needs to be called, but it removes a lot of magic, makes our methods more encapsulated, and gives us more room for nicely modifying w/o breaking changes before final.lacolaco commentedon Jul 12, 2016
how about
configureModuleSyncandconfigureModuleAsync?juliemr commentedon Jul 12, 2016
@laco0416 we would like
configureModuleto always be synchronous, since it is just storing the info to be set up later - this lets it be nested inside multipledescribeblocks and use only the latest. If it created anAppModuleevery time we calledconfigureModule, we could get weird side effects from creating a module more than once.lacolaco commentedon Jul 12, 2016
@juliemr Thanks, I understand.
fix(testing): add an explicit doAsyncPrecompilation step (#10015)
angular-automatic-lock-bot commentedon Sep 9, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.