Enzyme: TDD with Enzyme shallow and mount?

Created on 2 Jun 2016 · 14Comments · Source: enzymejs/enzyme

Sorry if I'm probably asking something stupid, but I don't find an answer to this question...

When I render a component using shallow or mount, the component is rendered in memory and is not attached to DOM.

This means that, while I run my tests, I don't actually see any output in the browser.

How am I supposed to do Test Driven Development if I can't see if the component I'm developing looks as it should? (css style, sizes etc)

Thanks.

question

Source

FezVrasta

Most helpful comment

When building a UI in TDD, don't you write acceptance tests first, and then build - and in no case do you need to see the UI while building?

ljharb on 2 Jun 2016

👍2

All 14 comments

IMO you don't really need to see the component when you're doing functionality to it. I mean you don't test if the component is green. You test perhaps the state of the component. At least that's how I do it.

Glenf on 2 Jun 2016

Yes but in TDD you create the whole component starting from a test. So, how are you supposed to see if the component looks like it should if you never have a chance to see it?

It would be like playing in Code in the Dark all the day 😨

FezVrasta on 2 Jun 2016

I see your point. But how do you write a test for something visual? If you can write a test to it you don't have to have a visual feedback because if the test passes then it's ok.

My experience with TDD is short and I might be wrong but you don't need to see the visual representation of the component to write the component. I'm not sure that styling the component would be something that can be tested very easily.

Glenf on 2 Jun 2016

You shouldn't "test" the style, but you should be able to see the result visually while you write the component.

Otherwise you'd have to run the whole app, open a page where the component is loaded, and use this context to style it.
The purpose of TDD is to avoid what I've described above, and just render the significant part of code to let you write tests on it, an see the result.

For example, if you have a dropdown, you want to test that the button is rendered, then you want to test that clicking it, the dropdown will open, and so on.
While you test the functionality, you can style the component.

Or maybe I'm missing something...

FezVrasta on 2 Jun 2016

The visual styling is an important part of the component but I think TDD cannot address it. That is why I do visual styling and design of the component outside TDD cycle. And to style a component you should be able to take it out of the app context and use some sort of style guide or sandbox for it.

So basically if you can write a test to it, then it can be done inside TDD cycle. And since test should be able to run in a headless CI env (at least in my case) it's important that real browser isn't needed.

Glenf on 2 Jun 2016

About your last sentence, using Xvfb I run my tests on real browsers even on CI. (which makes it easier to find bugs on the browsers the user actually uses)

I see your point about the "style guide / sandbox", but seems tedious having to switch between two environments to create a full component...

FezVrasta on 2 Jun 2016

I can't decide the CI setup so headless it is with PhantomJS when needed. And with over 300 tests I'd prefer running without browser.

It might be a bit tedious to switch but I'm in a different mindset when I style a component and when I write the functionality.

Glenf on 2 Jun 2016

Can you suggest me any tool for the style guide / sandbox stuff then? I'd like to try

Thanks

FezVrasta on 2 Jun 2016

Styleguidist is working in our setup.

https://github.com/sapegin/react-styleguidist

Glenf on 2 Jun 2016

Ah, I've tried it few days ago with no luck.. thanks anyway.

Using the Enzyme render, the component isn't rendered in the browser right? It would make possible for me to write a style test with this specific purpose :/

FezVrasta on 2 Jun 2016

When building a UI in TDD, don't you write acceptance tests first, and then build - and in no case do you need to see the UI while building?

ljharb on 2 Jun 2016

👍2

@FezVrasta - hopefully I am understanding your question here...You want to see the output(render) of your component to test it? I've been doing some tests for this myself. I had some issues with wrapper.equals(). I've resorted to running assertions off of expect(wrapper.debug()).to.eq(actualComponent) which outputs what the render should look like. I haven't noticed a case where this is hacky, so it might help your cause?

er-san on 2 Jun 2016

Enzyme's single responsibility is testing React component structure, state, props, and so on. If you're looking to test in the browser you can look at test runners like karma, and if you want to visually inspect your site for accuracy you can always run it locally and just look at it. Either way though, this would be out of the scope of enzyme. I encourage you to ask any clarifying questions you still have, but since this isn't actionable for us I'm going to close this out for now!

aweary on 6 Jun 2016

Sorry if I'm again here asking questions...

I really can't wrap my head around this. Let's say I have an input component.
In the test I focus it, write something inside, press enter to submit etc.

Something doesn't work, the text is not written inside the component.
If I could see what the test is doing, I could easily find that my component doesn't get focused.
Without seeing what the test is doing, I must do a guess work to find the problem.

It just seems pretty convenient to see the output of what your test is doing to easily spot bugs.
How can this problem be solved with Enzyme?

FezVrasta on 14 Jun 2016

Was this page helpful?

0 / 5 - 0 ratings