web-dev-qa-db-ja.com

コンポーネントがreact-testing-libraryを使用して適切な小道具でレンダリングされているかどうかをテストする

これらのコンポーネントのように、独立してテスト済みの別のコンポーネント（FetchNextPageButton）をレンダリングしているコンポーネントがいくつかあります。

const News = () => (
  <div>
    <h1>News</h1>
    ...
    <FetchNextPageButton query={NEWS_QUERY} path="viewer.news" />
  </div>
)

const Jobs = () => (
  <div>
    <h1>Jobs</h1>
    ...
    <FetchNextPageButton query={JOBS_QUERY} path="viewer.jobs" />
  </div>
)

const Posts = () => (
  <div>
    <h1>Posts</h1>
    ...
    <FetchNextPageButton query={POSTS_QUERY} path="viewer.posts" />
  </div>
)

問題は、すでに別の場所でテストされている機能に対して、これらの各コンポーネントにテストを追加する必要がないことです。そのため、コンポーネントがレンダリングされていることと、それに正しい小道具。

私はこのようなもので酵素でこれを簡単にテストすることができたでしょう：

expect(wrapper.find('FetchNextPageButton').props()).toMatchObject({
  query: NEWS_QUERY,
  path: "viewer.news"
})

だから、代わりに React Testing Library を使用してそれをテストするための最良のアプローチは何だろうと思います。

javascriptreactjsjestjsreact-testing-library
3
Emi

それが可能だと信じてはいけません。 RTLは、Reactのコンポーネントツリーではなく、DOMに対する検証に重点を置いているように見えます。

私が目にする唯一の回避策は、FetchNextPageButtonをモックしてすべての小道具を属性にレンダリングすることです。

jest.mock("../../../FetchNextPageButton.js", () => 
  (props) => <div data-test-id="FetchNextPageButton" {...props} />);
....
const { getByTestId } = render(<YourComponent />);
expect(getByTestId("FetchNextPageButton")).toHaveAttribute("query", NEWS_QUERY);
expect(getByTestId("FetchNextPageButton")).toHaveAttribute("path", "viewer.news");

確かに、これは小道具のプリミティブ値に対してのみスムーズですが、オブジェクトや関数などの検証はより困難になります。

考えてみてください、それはRTLの方法ではありませんが、各コンテナーのスコープでそれをチェックすることは大規模な作業であることに同意します（そしてそれを完全に無視すると、かなりリスクになります）。

PS toHaveAttributeは jest-dom

1
skyboyer