Idiomatic React Testing Patterns • Hacker News Board

Re: Idiomatic React Testing Patterns

#21

Post by cjcenizal » Wed, Jul 13, 2016, 6:58 PM UTC

shepmaster wrote: post #11

cjcenizal wrote: post #7

I've found the best testing pattern is to test the interface of the component, not the implementation. This means treating the component as an opaque function with inputs (props) and outputs (the rendered result). Your tests just need to that verify that different prop values result in the DOM changes or callbacks that you expect.

Do you use any tools to make the assertions on the resulting DOM simpler? What about any components that maintain internal state; do you just step them through the states and assert the DOM state as well?

I built this testing tool at a previous employer: https://github.com/smaato/react-test-kit. It's very very simple, it just exposes jQuery-like methods for querying the DOM (and internally uses Sizzle).

Here's an example of how we used react-test-kit to test a SearchBox component: https://github.com/smaato/ui-framework/blob/develop/src/fram...

Here's the interactive component example: http://smaato.github.io/ui-framework/#/searchbox

Re: Idiomatic React Testing Patterns

#22

Post by analyst74 » Wed, Jul 13, 2016, 7:00 PM UTC

shepmaster wrote: post #11

cjcenizal wrote: post #7

I've found the best testing pattern is to test the interface of the component, not the implementation. This means treating the component as an opaque function with inputs (props) and outputs (the rendered result). Your tests just need to that verify that different prop values result in the DOM changes or callbacks that you expect.

Do you use any tools to make the assertions on the resulting DOM simpler? What about any components that maintain internal state; do you just step them through the states and assert the DOM state as well?

I find it simplest to use shallow rendering in my unit tests as opposed to rendering the DOM, so the output I have to verify only contains things the component-under-test renders.

As for shallow render, you can use either the default Test Utilities or Enzyme, I personally find Enzyme's shallow render implementation much easier to work with.

Re: Idiomatic React Testing Patterns

#23

Post by analyst74 » Wed, Jul 13, 2016, 7:04 PM UTC

jitl wrote: post #2

See also Enzyme, a testing library specifically for React, that allows you to easy assert on both deep and shallow renders of the React DOM. https://github.com/airbnb/enzyme#basic-usage

If you use shallow render for your unit tests, Enzyme is much much better than Test Utilities. Just to name a few reasons:

- better event simulation

- easier to update prop

- allow setting and getting state

- easier to refresh after triggering changes

- comprehensive selector support

Re: Idiomatic React Testing Patterns

#24

Post by djacobs » Wed, Jul 13, 2016, 8:33 PM UTC

I looked through the patterns and I wonder what makes them 'idiomatic'?

I've found it useful to use wrapper libraries like Enzyme [0] and Teaspoon [1] when testing React components and interactions.

[0] https://github.com/airbnb/enzyme

[1] https://github.com/jquense/teaspoon

Re: Idiomatic React Testing Patterns

#25

Post by sotojuan » Wed, Jul 13, 2016, 9:20 PM UTC

Cool post but I'll play devil's advocate and ask what's so idiomatic about this. Can someone comment if this is what most the community is going? Not blaming the author at all, but skeptical of anything called "idiomatic" nowadays.

Re: Idiomatic React Testing Patterns

#26

Post by lhnz » Wed, Jul 13, 2016, 10:09 PM UTC

Do others agree with the `getComponent` pattern described there?

I do like it but I'm wary of moving away from the `beforeEach` pattern. The `beforeEach` pattern is much more common and is a consistent interface that engineers can easily pickup and won't need to recreate in every single test file.

Re: Idiomatic React Testing Patterns

#27

Post by jfdk » Thu, Jul 14, 2016, 4:20 AM UTC

lhnz wrote: post #26

Do others agree with the `getComponent` pattern described there? I do like it but I'm wary of moving away from the `beforeEach` pattern. The `beforeEach` pattern is much more common and is a consistent interface that engineers can easily pickup and won't need to recreate in every single test file.

I've found beforeEach breaks down super quickly as soon as you need to change the input props. Keeping things as purely functional as possible also helps manage complexity when writing tests in a large suite. You don't have to trace through all the beforeEach of each describe/context block. That said we use a healthy combination of both, as with everything know when to use the right tool.

Re: Idiomatic React Testing Patterns

#28

Post by [deleted] » Thu, Jul 14, 2016, 4:16 PM UTC

jfdk wrote: post #17

pietro wrote: post #9

From what Dan Abramov has been posting on Twitter recently, findDOMNode() is in the process of being deprecated, so rather than writing const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument( )); we should be writing let node; const component = TestUtils.renderIntoDocument( node = n}/> ); https://gist.github.com/gaearon/7f0e03d3028016bfabfad641720d...

Good to know, will update the examples when I have time. Not sure I'm a big fan of it though, doesn't seem as clear to a React noob what is going on with ref?

[deleted]