These are chat archives for airbnb/enzyme

15th
Feb 2016
Janusch
@janusch
Feb 15 2016 15:36
Hey, I am just getting started on testing with enzyme. I was wondering on how to test root components that are not supported?
Do you export them just for the tests?
I meant exported. Isn't it common that a root component is not exported, but one wants to render it for testing?
Leland Richardson
@lelandrichardson
Feb 15 2016 15:39
I guess I usually always separate component definition from rendering so it does not seem to be an issue that comes up
You can export it just for testing if you want
Or pull the component out into its own file
Janusch
@janusch
Feb 15 2016 15:46
Ok, that makes perfect sense. Thank you for the reply @lelandrichardson
Janusch
@janusch
Feb 15 2016 15:58
@lelandrichardson sorry to ask again, but I was hoping the test would pass and it does not. Is there anything obviously wrong here:
describe('wrapper', function() {
    it('renders', function() {
        const wrapper = mount(<AppRootComponent />);
        expect(wrapper.find('.container')).to.exist;
    });
});
How would you verify that the root component renders, it api calls in the componentWillMount() as well?
Do you think I should rather ask those general questions on SO or can you point me to an intro example/tutorial? @lelandrichardson
Jordan Harband
@ljharb
Feb 15 2016 16:03
@janusch what is it you think .to.exist will do?
i think you need .to.have.length(1)
Janusch
@janusch
Feb 15 2016 16:09
@ljharb thanks for the advice. I am just getting started, sorry. I just thought .to.exist sounds right when I say it ;)
Jordan Harband
@ljharb
Feb 15 2016 16:09
i'd recommend avoiding any matchers that aren't function calls
you can do expect(true).to.be.yogurt and it will pass
because no-ops only work if they're actually matchers, otherwise it passes when you didn't intend it to.
Janusch
@janusch
Feb 15 2016 16:11
I see. Is that why there is another expect.js lib?
Jordan Harband
@ljharb
Feb 15 2016 16:17
i don't think those are related, i think expect.js is just so you don't have to use a framework like mocha in order to use expect-based assertions
Janusch
@janusch
Feb 15 2016 16:18
ahh, that is good to know, thank you @ljharb for the info
Ehm, one last question, if you have the time. My test is still failing, and I think it is because the app renders first when api call is completed, is there a way to wait until the request completes, or should it be mocked with sinon? How do you go about this use case, where the state needs to be bootstrapped first?
Jordan Harband
@ljharb
Feb 15 2016 16:24
how does your component currently update when the api call is completed?
Janusch
@janusch
Feb 15 2016 16:28
@ljharb I am not sure if I understand you correct. The component gets data in componentWillMount() updates the state object and passes the parts of the state to different sub-components. It also sets a ready state to true
It is rendering now, the element it is mounted onto was not existing in the DOM, so I add that one in the before() hook.
Thanks a lot for holding my hand through writing the first passing test with enzyme!!!
Jordan Harband
@ljharb
Feb 15 2016 16:32
np!
you can also manually wrapper.setState() in your test if you want to simulate certain things
Janusch
@janusch
Feb 15 2016 16:36
oh that is good news, I'll do that with some sample data to test the sub-components. Have a good day! Mine is coming to an end now, talk to you soon!
Leland Richardson
@lelandrichardson
Feb 15 2016 16:57
@janusch getting in on the end of this conversation: if I were you, I would mock out your API with sinon or something similar, and have it return data asynchronously. Once this happens, you should be able to call wrapper.update() and then see the full component being rendered.I would then assert what you expect. Not sure if that helps you or not.