Skip to content
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

Bug: dependencies of a mock take precedence over root mocks #5239

Closed
RGunning opened this issue Mar 17, 2023 · 4 comments · Fixed by #5321
Closed

Bug: dependencies of a mock take precedence over root mocks #5239

RGunning opened this issue Mar 17, 2023 · 4 comments · Fixed by #5321
Assignees
Labels
bug Something isn't working released v14.7.3

Comments

@RGunning
Copy link

Description of the bug

with versions >= 14.5.0 mocking a standalone component that imports a pipe prevents mocking the pipe with a custom transform.

  TestBed.configureTestingModule({
      declarations: [
        // our component for testing
        StandaloneComponent,

        // the dependent component we want to mock
        MockComponent(DependencyComponent),
        // the pipe we want to mock with a custom transform
        MockPipe(StandalonePipe, () => 'standalonePipe'),
      ],
    })

prior to v14.5.0 instances of the standalone pipe would return 'standalonePipe'. However, post v14.5.0 it now returns '' because the mocking that occurs in MockComponent(DependencyComponent) takes precedence

An example of the bug

Link: https://stackblitz.com/edit/github-vfxlsb-nhqett?file=src%2Fexamples%2FTestStandaloneComponent%2Ftest.spec.ts&initialpath=?spec=TestStandaloneComponent

Expected vs actual behavior

MockComponent of a standalone component should not interfere with mocks defined at the root level

@RGunning RGunning added the bug Something isn't working label Mar 17, 2023
@RGunning
Copy link
Author

I also have a very similar example with angular material where a component being tested uses that MatExpansionPanel with lazy rendering (internally this uses CDK PortalModule for rendering) and also mocks a standaloneComponent that imports MatMenuModule (internally uses CDK PortalModule).

TestBed.configureTestingModule({
      declarations: [
        // our component for testing
        testComponent,
      ],
      imports: [
        MatExpansionModule,

        // mocked standalone Component that uses MatMenuModule
        MockComponent(StandaloneComponent),
      ],
    })

Prior to v14.5.0 this would use the real MatExpansionModule including it's dependencies in the testComponent. But since v14.5.0 this now uses a mockedVersion of the PortalModule due to MockComponent(StandaloneComponent) taking precedence over the real implementation.

link: https://stackblitz.com/edit/github-vfxlsb-urwutc?file=src%2Fexamples%2FTestStandaloneComponent%2Ftest.spec.ts&initialpath=?spec=TestStandaloneComponent

this second example can be mitigated by adding

 beforeAll(() => {
        ngMocks.globalKeep(PortalModule, true);
    });

    afterAll(() => {
        ngMocks.globalWipe(PortalModule, true);
    });

but this is not intuitive and it would be expected that if you are importing the whole MatExpansionPanel it would work without having to override MockComponent functionality

@satanTime
Copy link
Member

Hi there,

thanks for the report.

The problem here is different, all of them are standalone, whereas you provide them as declarations of TestBed, so basically each one works on its own level.

Why do you not use MockBuilder?
It respects inheritance and mocks things correctly:

beforeEach(() => MockBuilder(StandaloneComponent).mock(StandalonePipe, () => 'standalonePipe'));

@satanTime
Copy link
Member

Aha - anyway it was in issue with MockBuilder, working on a fix.

satanTime added a commit to satanTime/ng-mocks that referenced this issue Mar 26, 2023
satanTime added a commit to satanTime/ng-mocks that referenced this issue Mar 26, 2023
satanTime added a commit that referenced this issue Mar 26, 2023
Bug: dependencies of a mock take precedence over root mocks #5239
@satanTime
Copy link
Member

v14.7.3 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released v14.7.3
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants