5 ms·
> Hmm, I'm not sure I follow the part of static imports ====== COMPONENT FILE import PeskyChild from './PeskyChild'; // THIS IS A STATIC IMPORT. STAT
by azangru 4y ago
> Hmm, I'm not sure I follow the part of static imports
====== COMPONENT FILE
import PeskyChild from './PeskyChild'; // THIS IS A STATIC IMPORT. STATIC IMPORTS IN ES6 ARE HOISTED
const MyComponent = () => (<div><PeskyChild /></div>);
====== TEST FILE
import { render } from '@testing-library/react';
import MyComponent from './MyComponent';
// THIS ATTEMPTS TO MOCK A STATIC IMPORT. IT WON'T WORK SOON-ISH
jest.mock('./PeskyChild', () => () => <div data-test-id="mocked-child-component" />)
describe('MyComponent', () => {
it('is awesome', () => {
render(<MyComponent />)
});
});
- Vinnl 4y agoRight, I guess it's the part where it will stop working that I'm not aware of :) But still, in that case I'm not sure why you'd need to mock <PeskyChild>. It's part of what the user is expecting to see, after all. (I used to see unit tests as distinct from integration tests, but really, it's pretty arbitrary where to draw the line around a "unit". If I refactor some lines out of a function/component into a separate file, should that now suddenly have its own unit tests, and be mocked out of its parent?)
- azangru 4y ago> But still, in that case I'm not sure why you'd need to mock <PeskyChild>. Not every child is a pesky one; but suppose it makes a network request, or tries to read something from IndexedDB, or relies on window.matchMedia or IntersectionObserver. And you don't want to deal with this stuff when you are testing one of its (grand)parents.
- Vinnl 4y agoYeah exactly, that's what I was alluding to before about only mocking the hook/function that performs those side effects. But I guess if mocking modules will no longer be possible (still haven't seen why that should happen), that will still be problematic too.