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

feat: introduce `TestBed.overrideProvider` #16725

Merged
merged 1 commit into from May 15, 2017

Conversation

Projects
None yet
6 participants
@tbosch
Member

tbosch commented May 11, 2017

This allows to overwrite all providers for a token, not matter
where they were defined.

This can be used to test JIT and AOT’ed code in the same way.

Design doc: https://docs.google.com/document/d/1VmTkz0EbEVSWfEEWEvQ5sXyQXSCvtMOw4t7pKU-jOwc/edit?usp=sharing

Please check if the PR fulfills these requirements

What kind of change does this PR introduce? (check one with "x")

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior? (You can also link to an open issue here)

What is the new behavior?

Does this PR introduce a breaking change? (check one with "x")

[ ] Yes
[ ] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...

Other information:

@googlebot googlebot added the cla: yes label May 11, 2017

@tbosch tbosch requested a review from vicb May 11, 2017

@vicb

vicb approved these changes May 11, 2017

a few nits, otherwise 👍

feat: introduce `TestBed.overrideProvider`
This allows to overwrite all providers for a token, not matter
where they were defined.

This can be used to test JIT and AOT’ed code in the same way.

Design doc: https://docs.google.com/document/d/1VmTkz0EbEVSWfEEWEvQ5sXyQXSCvtMOw4t7pKU-jOwc/edit?usp=sharing
useFactory: Function,
deps: any[],
}): void;
static overrideProvider(token: any, provider: {useValue: any;}): void;

This comment has been minimized.

@IgorMinar

IgorMinar May 12, 2017

Member

I don't know how this method overloads will show up in the api docs. can you check?

@IgorMinar

IgorMinar May 12, 2017

Member

I don't know how this method overloads will show up in the api docs. can you check?

This comment has been minimized.

@tbosch

tbosch May 12, 2017

Member

How can I get a preview with the new docs infrastructure?

@tbosch

tbosch May 12, 2017

Member

How can I get a preview with the new docs infrastructure?

This comment has been minimized.

@gkalpak

gkalpak May 15, 2017

Member

(You should have gotten a preview (comment with link on this PR), but didn't due to a bug on master. It has been fixed, so rebasing on latest master will create a preview.)

@gkalpak

gkalpak May 15, 2017

Member

(You should have gotten a preview (comment with link on this PR), but didn't due to a bug on master. It has been fixed, so rebasing on latest master will create a preview.)

@@ -89,6 +96,13 @@ export declare class TestBed implements Injector {
static overrideDirective(directive: Type<any>, override: MetadataOverride<Directive>): typeof TestBed;
static overrideModule(ngModule: Type<any>, override: MetadataOverride<NgModule>): typeof TestBed;
static overridePipe(pipe: Type<any>, override: MetadataOverride<Pipe>): typeof TestBed;
static overrideProvider(token: any, provider: {

This comment has been minimized.

@IgorMinar

IgorMinar May 12, 2017

Member

shouldn't this api be closer to the regular provider definition? why doesn't overrideProvider just take Provider as the only argument?

@IgorMinar

IgorMinar May 12, 2017

Member

shouldn't this api be closer to the regular provider definition? why doesn't overrideProvider just take Provider as the only argument?

This comment has been minimized.

@tbosch

tbosch May 12, 2017

Member

Why not the regular Provider:

  • we require deps as we don't want to rely on runtime metadata.
  • that's also the reason why a regular useClass does not work.

Having the token be the first argument is more inline with the other override methods as well.

@tbosch

tbosch May 12, 2017

Member

Why not the regular Provider:

  • we require deps as we don't want to rely on runtime metadata.
  • that's also the reason why a regular useClass does not work.

Having the token be the first argument is more inline with the other override methods as well.

This comment has been minimized.

@IgorMinar

IgorMinar May 12, 2017

Member

ok. that makes sense. thanks!

@IgorMinar

IgorMinar May 12, 2017

Member

ok. that makes sense. thanks!

@jasonaden jasonaden merged commit 39b92f7 into angular:master May 15, 2017

4 checks passed

ci/circleci Your tests passed on CircleCI!
Details
cla/google All necessary CLAs are signed
code-review/pullapprove Approved by all reviewer groups.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

asnowwolf added a commit to asnowwolf/angular that referenced this pull request Aug 11, 2017

feat: introduce `TestBed.overrideProvider` (#16725)
This allows to overwrite all providers for a token, not matter
where they were defined.

This can be used to test JIT and AOT’ed code in the same way.

Design doc: https://docs.google.com/document/d/1VmTkz0EbEVSWfEEWEvQ5sXyQXSCvtMOw4t7pKU-jOwc/edit?usp=sharing

@tbosch tbosch deleted the tbosch:modules3 branch Aug 14, 2017

juleskremer added a commit to juleskremer/angular that referenced this pull request Aug 28, 2017

feat: introduce `TestBed.overrideProvider` (#16725)
This allows to overwrite all providers for a token, not matter
where they were defined.

This can be used to test JIT and AOT’ed code in the same way.

Design doc: https://docs.google.com/document/d/1VmTkz0EbEVSWfEEWEvQ5sXyQXSCvtMOw4t7pKU-jOwc/edit?usp=sharing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment