<p>microCMSはヘッドレスCMSを提供するサービスです。microCMSのようなヘッドレスCMSを使うことで、コンテンツの編集や管理などを行うバックエンド(こちらがヘッドレスCMS)と、バックエンドから取得したコンテンツを表示するフロントエンドを分離することができます。対して、WordPressなどの従来のCMSはコンテンツの編集や管理、表示など全てを管理します。</p><h3 id="hf7c8ef7d1b">JAMStackとは</h3><p><strong>J</strong>avaScript <strong>A</strong>PI <strong>M</strong>arkup の頭文字を取ったもので、<span style="color:#333333">JavaScriptとAPIとMarkupを組み合わせたWebアプリケーションアーキテクチャです。</span><br><span style="color:#333333">JavaScriptは</span><span style="color:#000000">Webページの中でのユーザーの状態（State）や動的に変化する要素について処理します。</span><br><span style="color:#333333">APIはJavaScriptからバックエンドのAPI(microCMS)を呼び出し、データの参照などをおこないます。</span><br><span style="color:#333333">MarkupはWEBページで配信される静的なHTMLのことを指します。</span><br><span style="color:#333333">Next.jsは状態管理、APIの呼び出し、静的なHTMLの生成全てをカバーします。</span></p>

microCMS + Next.js でJamStackブログを作る

<h2 id="h46a4f5cea9">Reactで書いた画面をテストするには</h2><p>Reactで書いた画面をテストしたいとなった時に、思いつくのは以下の4つの方法があるかと思います。</p><ul><li>目視で動作を確認？</li><li>puppeteer(E2E)？</li><li>enzyme？</li><li>React Testing Library？</li></ul><p>次に上記の手法の特徴を考えます。</p><h3 id="h763dd6d28a">目視で動作を確認</h3><p>画面が単純なうちはいいですが、画面が増えたり複雑になっていくと動きを網羅するのに時間がかかります。<br>また、リファクタ前後で挙動が同じであることを確認しないとデグレが起きてしまうことが考えられます。<br>動きの仕様を覚えておくことも大変です。</p><h3 id="h5f81ec63d4">puppeteer(E2E)</h3><p>起動が遅かったり、実行時間が長かったりします。<br><code>page.waitFor(2000)</code>とか書かなければいけないのも面倒です。<br>正しいテストでも落ちたり、落ちなかったりして不安定になりやすいです。</p><h3 id="hc089b43330">enzyme</h3><p>TDD like にテストが書けるため、Unit テストが書きやすいです。<br>コンポーネントの見た目の挙動よりも、コードの実装に対するテストが書きやすいです。<br>ユーザに見えている見た目部分以外をテストしがちになります。</p><h3 id="hebe7f9a775">React Testing Library</h3><p>BDD(振舞駆動開発)  likeにテストが書けるため、integration テストが多くなります。<br>コードの実装よりもユーザに対する見た目や、挙動がテストできます。<br>full dom レンダリングしか使えないので API 通信や redux などは mock しておく必要があります。</p><h2 id="hd57134ef5a">どれを使うべきか？</h2><p>ではどれを使うべきなのでしょうか？<br>公式はReact Testing Libraryを勧めています。</p><pre><code>We recommend using React Testing Library
which is designed to enable and encourage
writing tests that use your components as the end users do.</code></pre><p>EnzymeもReactに関するテスト方法を調べるとよく出てくる方法なのですが、React Testing LibraryはEnzymeに代わるものとしてリリースされたものです。<br><br>VercelのCEOのツイートで以下のようなツイートがありました。</p><pre><code>Write tests. Not too many. Mostly integration.

テストを書こう。多く書かなくていい。ほとんどインテグレーションテストでいい。</code></pre><p>上記ツイートから画面のテストに関しては、単体テストを書くよりも画面全体の振る舞いをテストした方が良い、つまりTDDよりもBDDを書いた方が良いのではと考え、React Testing Libraryを使うことにしました。</p><h2 id="h0e8f03f5fa">React Testing Libraryのセットアップ</h2><h3 id="h60c2a0418f">create-react-app</h3><p>create-react-app を使用した場合は、デフォルトで使用可能です。</p><h3 id="heacd9143a8">自分でセットアップする場合</h3><p>以下を実行し、必要なライブラリをダウンロードします。</p><pre><code>yarn add -D jest jest-dom @testing-library&#x2F;react
　　@testing-library&#x2F;jest-dom @testing-library&#x2F;dom babel-jest</code></pre><p>setupTests.jsに以下を書き、setUp時にimportするようにします。これをしないと toBeInTheDocumentなどの、jest-domアサーション関数が使えません。</p><pre><code>import &quot;@testing-library&#x2F;jest-dom&#x2F;extend-expect&quot;;</code></pre><h2 id="h024f16374c">アサーション関数</h2><p>アサーション関数には以下が使えます。</p><ul><li>jest のアサーション関数<ul><li>表示時にこの関数が呼ばれているかなどを主に確認</li><li>要素の存在確認にも使うこともある</li></ul></li><li>jest-dom のアサーション関数<ul><li>要素の存在確認は主にこちらのアサーション関数を使う</li></ul></li></ul><h3 id="hb7ee278f0b">jestのアサーション関数</h3><ul><li>toHaveLength<ul><li>いくつ存在するかを確認</li></ul></li><li>toHaveBeenCalled(With)<ul><li>mock した関数が呼ばれているかを確認</li></ul></li><li>...<a href="https://jestjs.io/docs/ja/expect" target="_blank" rel="noopener noreferrer">その他</a></li></ul><h3 id="h04a8cc770e">jest-domのアサーション関数</h3><ul><li>toBeInTheDocument<ul><li>要素がドキュメントに存在することを確認</li></ul></li><li>toBeDisabled<ul><li>要素が disabled になっていることを確認</li></ul></li><li>toBeEnabled<ul><li>要素が enabled になっていることを確認</li></ul></li><li>toHaveFormValues<ul><li>Form の key,value の対応を確認できる</li></ul></li><li>...<a href="https://github.com/testing-library/jest-dom" target="_blank" rel="noopener noreferrer">その他</a></li></ul><h2 id="he69d91c4e4">React Testing Libraryの機能</h2><p>React TestingLibraryを使用するには、まず以下のようにimportする必要があります。</p><pre><code>import { render, fireEvent, waitFor, screen, within } from &#x27;@testing-library&#x2F;react&#x27;</code></pre><p>主に5つの機能があり、使いたいものをimportすることになります。<br>それぞれの役割は簡単にいうと以下になります。</p><ul><li>render<ul><li>DOMにReactのエレメントをレンダーします</li><li>テストしたいcomponentに対して最初にrenderをする必要があります</li></ul></li><li>screen<ul><li>レンダーされた内容はscreenが持っています</li><li>この後説明するクエリ関数を持っています</li></ul></li><li>fireEvent<ul><li>イベントを発生させてボタンのクリックなどのユーザアクションをシミュレートします</li></ul></li><li>waitFor<ul><li>非同期処理が完了するのを待ちます</li></ul></li><li>within<ul><li>DOM要素を受け取り、それをscreenが持っているような、クエリ関数にバインドします</li><li>div単位で確認したい場合などに便利です</li></ul></li></ul><h3 id="h6f56b2ce31">render時に取得できる機能</h3><pre><code>const {debug, rerender} = render(&lt;App &#x2F;&gt;)</code></pre><ul><li>debug<ul><li>その時点での DOM の構造を確認できます(デバッグ用)</li></ul></li><li>rerender<ul><li>再レンダリングすることができます</li></ul></li></ul><h2 id="h3ef214ed92">要素の取得</h2><p>テストをするにはDOM要素を取得する必要があります。<br>screenはDOM要素を取得するために大きく分けて以下3つのクエリ関数を持っています。</p><ul><li>getByXXX</li><li>queryByXXX</li><li>findByXXX</li></ul><h3 id="hc3137dd44b">getByXXX</h3><ul><li>getByText<ul><li><code>expect(screen.getByText(&#x27;0&#x27;)).toBeInTheDocument()</code></li><li> 上記の書き方で画面に<code>0</code> が存在することを確認します</li></ul></li><li>getByRole<ul><li>aria-label属性で要素を取得します</li><li>buttonやtableなど暗黙的なroleもあります</li><li><code>screen.getByRole(&#x27;&#x27;);</code> のように利用できないroleを指定すると、利用できるroleをサジェストしてくれます</li></ul></li><li>getByLabelText<ul><li><code>&lt;label for=&quot;search&quot; &#x2F;&gt;</code></li></ul></li><li>getByPlaceholderText<ul><li><code>&lt;input placeholder=&quot;Search&quot; &#x2F;&gt;</code></li></ul></li><li>getByAltText<ul><li><code>&lt;img alt=&quot;profile&quot; &#x2F;&gt;</code></li></ul></li><li>getByDisplayValue<ul><li><code>&lt;input value=&quot;JavaScript&quot; &#x2F;&gt;</code></li></ul></li></ul><h3 id="h825a006ac5"> queryByXXX</h3><ul><li>queryByText</li><li>queryByRole</li><li>queryByLabelText</li><li>queryByPlaceholderText</li><li>queryByAltText</li><li>queryByDisplayValue</li></ul><h3 id="hd5ced78c31">findByXXX</h3><ul><li>findByText</li><li>findByRole</li><li>findByLabelText</li><li>findByPlaceholderText</li><li>findByAltText</li><li>findByDisplayValue</li></ul><h2 id="h2d85311077">getBy・queryBy・findByの違い</h2><ul><li>getByXXX<ul><li>要素が取得できなかった場合はエラーになります</li></ul></li><li>queryByXXX<ul><li>要素がない場合でもエラーにならないため、要素がないことの確認に使えます</li></ul></li><li>findByXXX<ul><li>非同期処理で、今は画面に存在しないが、最終的に存在する要素についての確認に使います</li></ul></li></ul><h2 id="hb95b1067af">複数要素の取得</h2><p>画面に<code>0</code> が複数ある場合、<code>XXXByText</code>使うとエラーになります。複数要素を確認したい場合は<code>XXXAllByText</code>を使います。<br>例えば<code>0</code> が 2 つあることを確認したい場合は、<code>expect(screen.getAllByText(&#x27;0&#x27;)).toHaveLength(2)</code> とすることで確認できます。</p><h2 id="h0f4708dfbe">data-testid属性</h2><p>React Testing Libraryでは<code>data-testid</code>という属性が使えます。data-testidを持つ要素はXXXByTestidで取得することができます。</p><pre><code>&lt;button data-testid=&#x27;plus-button&#x27;&gt;+&lt;&#x2F;button&gt;</code></pre><h2 id="h9c9a59c93c">withinでDOMを分割する</h2><p>たとえばファイルアップロードフォームと検索フォームがある画面があるとします。両方のフォームにリセットボタンがある場合は以下でも確認ができます。</p><pre><code>expect(screen.getAllByText(&#x27;リセット&#x27;)).toHaveLength(2)</code></pre><p>ただ、ファイルアップロードの form に一つリセットを持っていて、検索フォームにもリセットを一つ持っていることを確認できた方がより確実です。<br>その場合はwithinでDOMを分割します。ファイルアップロードフォームに<code>data-testid=&#x27;upload-form&#x27;</code> を持たせて以下のようにすると、ファイルアップロードフォームだけを持った DOM を取得できます。</p><pre><code>const uploadForm = within(screen.getByTestId(&#x27;upload-form&#x27;))
expect(uploadForm.getByText(&#x27;リセット&#x27;)).toBeInTheDocument()</code></pre><p>こうすることでファイルアップロードフォームにはリセットという要素が1つしかないので<code>getByText</code> を使用することができます。</p><h2 id="ha214098e44">まとめ</h2><p>今回はReactで書いた画面のテスト方法として、React Testing Libraryの使い方を説明しました。<br>今回説明した内容だけで簡単にテストを書くことが可能です。ただしAPI通信を行なっている画面の場合は、その部分をmockしないといけないため、もう少し工夫が必要です。それはまた別の記事で説明したいと思います。<br></p><h2 id="h3de35099b3">参考</h2><ul><li><a href="https://qiita.com/ossan-engineer/items/4757d7457fafd44d2d2f" target="_blank" rel="noopener noreferrer">React Testing Library の使い方</a></li></ul>