[Request] expose detectChanges function

[GregOnNet]

Before we start

🙏 Thank you for providing this library. It really helps my team to create solid maintainable tests.

Description

The render function gives access of the fixture corresponding to the Component that is tested.
In many tests I find my self using fixture just to use detectChanges.
It would be nice to use detectChanges directly

const { detectChanges } = render(Component)

Benefit

If fixture is only used for execute detectChanges the direct use of detectChanges makes the test more readable. In other words detectChanges goes hand in hand with the existing helper-functions (e.g. type, click, dblClick).

// Before
const { getByTestId, click, fixture } = render(Component);

const btn = getByTestId('my-id');
click(btn);
tick(600);
fixtue.detectChanges();
expect(btn).toBeDisabled();

// After
const { getByTestId, click, detectChanges } = render(Component);

const btn = getByTestId('my-id');
click(btn);
detectChanges();
expect(btn).toBeDisabled();

Use Case

Entering a value to an input triggers an asynchronous operation that might be delayed by debounceTime.

1. The first detectChanges coming from type triggers the asynchronous operation
2. After flushing the async tasks a second detectChanges needs to be called updating the view with the loaded data.

describe('When an entered company name/ticker has at least 2 characters', () => {
  it(
    'searches and lists duplicate candidates as the user types', 
    fakeAsync(async () => 
  {
    const { type, getByTestId, getAllByTestId, fixture } = await 
    render(CompanyCreateComponent, renderOptions);
    
    type(getByTestId('name-or-ticker'), 'GO');
    tick(600);
    fixture.detectChanges();

    expect(getAllByTestId('name-duplicate')).toHaveLength(1);
  }));
});

Contribution

• I would create an PR for this feature if you find it valuable, too.

[timdeschryver]

The events are calling detectChanges() automatically, so you shouldn't have to.
Do you have a case where you do have to call detectChanges? If so, I would rather fix that problem, instead of exposing detectChanges.

[GregOnNet]

Hi,

thanks for the quick reply.
I know about the fact that events calling detectChanges, which is great.
I added an example test to the description (see Use Case).

As far as I know there are cases where detectChanges needs to be called n-times if an event of the template triggers asynchronous operations that may be delayed due UX-reasons.

[timdeschryver]

That makes sense.

If you want Greg, you can create a PR for this.