TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Idiomatic React Testing Patterns

64 点作者 jfdk将近 9 年前

8 条评论

jitl将近 9 年前
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.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;airbnb&#x2F;enzyme#basic-usage" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;airbnb&#x2F;enzyme#basic-usage</a>
评论 #12088760 未加载
评论 #12087746 未加载
cjcenizal将近 9 年前
I&#x27;ve found the best testing pattern is to test the interface of the component, not the implementation.<p>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.
评论 #12088202 未加载
评论 #12088277 未加载
评论 #12088194 未加载
pietro将近 9 年前
From what Dan Abramov has been posting on Twitter recently, findDOMNode() is in the process of being deprecated, so rather than writing<p><pre><code> const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument( &lt;MyComponent {...props} &#x2F;&gt; )); </code></pre> we should be writing<p><pre><code> let node; const component = TestUtils.renderIntoDocument( &lt;MyComponent {...props} ref={n =&gt; node = n}&#x2F;&gt; ); </code></pre> <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;gaearon&#x2F;7f0e03d3028016bfabfad641720d3de1" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;gaearon&#x2F;7f0e03d3028016bfabfad641720d...</a>
评论 #12088392 未加载
djacobs将近 9 年前
I looked through the patterns and I wonder what makes them &#x27;idiomatic&#x27;?<p>I&#x27;ve found it useful to use wrapper libraries like Enzyme [0] and Teaspoon [1] when testing React components and interactions.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;airbnb&#x2F;enzyme" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;airbnb&#x2F;enzyme</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jquense&#x2F;teaspoon" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jquense&#x2F;teaspoon</a>
sotojuan将近 9 年前
Cool post but I&#x27;ll play devil&#x27;s advocate and ask what&#x27;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 &quot;idiomatic&quot; nowadays.
haukur将近 9 年前
It can be very helpful to define all the different states (as props) for the set of components you&#x27;re building. The data can be static or the result of dynamic calls to API endpoints (both approaches have benefits and trade-offs). For instance, if you&#x27;re building a page with a list of items and at most 10 should be shown at a time, you could define the empty state (0 items), the half-full (1-10 items) and the overloaded state (11+ items, requiring pagination). Then you can implement the actual UI.<p>When this is done (and you&#x27;re happy with the way it looks), you can make your test suite iterate over each of the different states and capture a screenshot of the UI. When something changes, you will know (the test suite should diff it). This approach is obviously mostly for presentation rather than functionality.<p>The benefits are not limited to testing, this is also very helpful in development, since you could switch between different states very quickly without having to constantly change URLs (for different API results). One method is using a dropdown overlay (only present in the development build). It&#x27;s also very helpful during code review.
tengbretson将近 9 年前
In my experience, as long as you have a well tested data model and use proptypes&#x2F;Flow&#x2F;TypeScript, testing the components themselves becomes almost entirely irrelevant.<p>However, I can see the utility of component testing if I were wrapping something like Ace editor or a jQuery plugin or something of that nature.
评论 #12088452 未加载
评论 #12088425 未加载
评论 #12088221 未加载
lhnz将近 9 年前
Do others agree with the `getComponent` pattern described there?<p>I do like it but I&#x27;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&#x27;t need to recreate in every single test file.
评论 #12091603 未加载