This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit da4a3f1:

Codecov Report

Merging #668 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #668   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           24        24           
  Lines          593       593           
  Branches       148       148           
=========================================
  Hits           593       593           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4ad3673...da4a3f1. Read the comment docs.

I was looking into extending the config for Angular Testing Library, to add default imports. This way, Angular Testing Library retrieves the config with getConfig to include these default imports to the Dependency Injection.

For example:

beforeEach(() => {
  configure({
    defaultImports: [ReactiveFormsModule],
  });
});

test('test 1', async () => {
 await render(MyComponent)
})

test('test 2', async () => {
 await render(MyComponent)
})

// VS

test('test 1', async () => {
 await render(MyComponent, { imports: [ReactiveFormsModule] })
})

test('test 2', async () => {
 await render(MyComponent, { imports: [ReactiveFormsModule] })
})

An alternative could be that Angular Testing Library provides its own angularConfigure method?
What do you think?

Interesting. I'm not sure you need this method to do that. You could simply make your own configure wrapper that takes custom config properties and forwards along the rest. I think it would be dangerous to set the DOM Testing Library config with properties it doesn't support.

That said, we use getConfig in user-event so it's not just exposed by accident and should probably be typed for that reason.

I was looking into extending the config for Angular Testing Library, to add default imports.

I'd be careful with adding additional properties to the config object from @testing-library/dom. This could create conflicts if we decide to add properties with names you're already using.

Have you considered implementing your own configure that forwards excess properties to the configure from DTL and has a separate property for the config of the angular testing library (or vice-versa) e.g.

import { configure } from '@testing-library/angular';

configure({ property: 'foo', someFlag: false, dom: domTestingLibraryConfig })

I guess this is currently problematic for any library extending the config of DTL.

I have not, but I think I'm going to go with your proposition @eps1lon 👍.

The current implementation looks like this, but I'm not too happy about it.

function configure(config: Partial<Config>) {
  dtlConfigure({
    defaultImports: config.defaultImports,
  } as Partial<dtlConfig>);
}

That said, we use getConfig in user-event so it's not just exposed by accident and should probably be typed for that reason.

@kentcdodds feel free to close or merge this PR.

🎉 This PR is included in version 7.17.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀