Another works Developers Blog

<p>こんにちは、Another worksのCTO、塩原です。</p>
<p>最近、Another worksではフロントエンドのテスト作成を始める動きがあり、私たちも徐々にテストを書き始めています。<br>
LT会も毎月開催する中で、せっかくなのでそこで話した内容の一部を記事にして公開することにしました。</p>
<h1>今回の目的</h1>
<p>まだテストがほとんど書かれていない状況ですので、まずは「テストを書く」こと自体を習慣化したいと考えています。その一環として、カバレッジレポートが作成できると、テストが増えていく過程を可視化するための一つの指標となり、レビュワーがどれだけテストを網羅して書けているかの確認にも活用できると思います。</p>
<p>ただし、全体のカバレッジレポートだけでは、まだテスト自体をほとんど書いていない現状では、PRを作成する際に新たに書かれたテストを可視化するのが難しいと感じています。そこで、提出するPRの差分がどれだけテストを含んでいるかを可視化するため、新たな取り組みを始めました。</p>
<h1>使用技術</h1>
<ul>
<li>jest &quot;^29.5.0&quot;</li>
<li>@testing-library/react &quot;^14.0.0&quot;</li>
</ul>
<h1>やらなければならないこと</h1>
<p>やらなければならないことは主に二つです。</p>
<ul>
<li>特定のファイルに対するカバレッジレポートを出力すること</li>
<li>生成したカバレッジレポートをPRのコメントとして投稿すること</li>
</ul>
<h1>特定のファイルに対するカバレッジレポートの出力</h1>
<p>まず、jestのカバレッジレポートで特定のファイルに対して出力する方法ですが、以下の公式ドキュメントに方法が記載されています。<br>
https://jestjs.io/ja/docs/cli#--collectcoveragefromglob</p>
<pre><code>$ jest &quot;--coverage&quot; &quot;--collectCoverageFrom=${file_path1}|${file_path2}&quot;
</code></pre>
<p>&quot;|&quot;で区切ることで、複数のファイルに対するカバレッジレポートを一度に出力することが可能です。</p>
<h1>GitHubのPR差分に対して実行する</h1>
<p>GitHubのPR差分を取得するためには、<code>git diff</code>を使用します。ファイルは先ほどのglobパターンに適応するために&quot;|&quot;で区切る必要があります。また、当社ではモノレポを採用しているため、&quot;fc_client_web&quot;というプロジェクトのディレクトリ名を削除しています。</p>
<pre><code>- name: coverage-report
        id: coverage-report
        run: |
          change_files=($(git diff --name-only origin/${GITHUB_BASE_REF}...origin/${GITHUB_HEAD_REF} | grep -E '^fc_client_web/src/.*\.ts(x)?$'))
          for i in &quot;${!change_files[@]}&quot;; do
            change_files[$i]=${change_files[$i]//fc_client_web\//}
          done
          IFS=&quot;|&quot;;files=&quot;${change_files[*]}&quot;;unset IFS;
          npm run unit -- --coverage --collectCoverageFrom=$files --coverageReporters=json-summary
</code></pre>
<h1>生成したカバレッジレポートをPRのコメントとして投稿すること</h1>
<p>カバレッジレポートの生成までは上記で行うことができました。<br>
最後にPRコメントに投稿する方法ですが、<br>
<code>--coverageReporters=json-summary</code> こちらのオプションを付与することで、json形式でレポートの結果を吐き出してくれるのでそのjsonをmarkdownに加工してPRコメントに投稿することができます</p>
<pre><code>- name: Post jest coverage comments
        uses: actions/github-script@v6
        env:
          GH_TOKEN: ${{ github.token }}
          COMMENT: ${{ steps.coverage-report.outputs.GITHUB_ENV }}
        with:
          script: |
            const fs = require('fs')
            const data = JSON.parse(fs.readFileSync('./fc_client_web/coverage/coverage-summary.json', 'utf8'))
            let mdTable = &quot;| File Path | Lines % | Functions % | Statements % | Branches % |\n| --- | --- | --- | --- | --- |\n&quot;;

            for (const path in data) {
                const coverage = data[path];
                mdTable += `| ${path.replace('/home/runner/work/FC_Cloud/FC_Cloud/fc_client_web/', '')} | ${coverage.lines?.pct || 0} | ${coverage.functions?.pct || 0} | ${coverage.statements?.pct || 0} | ${coverage.branches?.pct || 0} |\n`;
            }
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: mdTable
            })
</code></pre>
<p>結果としてはこのようにPRコメントに差分のあるファイルだけがカバレッジレポートとして表示されます。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/52e7bf7f-c3dc-4d7d-a7e1-899244ec1afd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-06-2613.27.48.png" alt="スクリーンショット2023-06-2613.27.48.png"></p>
<h1>まとめ</h1>
<p>カバレッジレポートはあくまでも数値指標の一つでしかないですが、<br>
テストを書く際のモチベーションとしても機能すればと思いこの仕組みを取り入れてみました。<br>
テストについてはまたどこかで記事にできればと思います。</p>


Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

<h1>こんな悩みはありませんか？</h1>
<ul>
<li>書いたコードに予期せぬバグがあるのではと心配になり、夜も眠れない</li>
<li>変更後に致命的なバグが突然発生する悪い夢にうなされる</li>
</ul>
<h1>テストの目的</h1>
<ul>
<li>「想定通りに動くのか」を担保するため</li>
<li>開発者自身のため</li>
<li>変更に強い仕様書をつくる</li>
</ul>
<h1>テストってどうやってを書くの？</h1>
<h2>Testing Torophy</h2>
<ul>
<li>JSテスト界の大御所Kent.Cが提唱するテストのコンセプト</li>
<li>体積が大きいところほど重要であるとしている(ここではIntegrationが最も大きい)</li>
</ul>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/16c8cc69-2e11-9fbf-5ac8-158943e082fd.png" width="550">
<h2>トレードオフの発生</h2>
<ul>
<li>テストの実行スピード</li>
<li>工数</li>
<li>カバレッジ</li>
</ul>
<img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F82363%2Fda49f860-4296-9ab4-cc08-186ecc8888ad.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&w=1400&fit=max&s=350ca04cddac9646515b2f4a526d9df0" width="700">
<h2>Kent.Cの方針</h2>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a7aec6d7-3bd6-4fc7-b81e-3c3ad21eaf6b%2FKentCDoddsHeadshot.png" width="300">
Kent.Cがtesting-libraryのドキュメント内で言っていたこと。
<ul>
<li>テストはアプリケーションの利用方法に似ているほど信頼性が得られるのさ</li>
<li>実装の詳細をテストしないことを勧めるよ（実施してもいいけどね)</li>
</ul>
<h1>テストって何を書けばいいの？</h1>
<h2>実際に書いてみる</h2>
<p><strong>テスト対象</strong><br>
Incrementボタンを押すと、数字が1増えて表示される。(初期表示は0)<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/de2c54e1-b76b-06b9-1d92-420e258ed729.png" width="200"></p>
<pre><code class="language-react">export function Counter() {
  const [count, setCount] = useState(0);
  const increment() {
    setCount(count + 1);
  }
  return (
    &lt;&gt;
      &lt;div&gt;Number: {count}&lt;/div&gt;
      &lt;div&gt;
        &lt;button onClick={increment}&gt;Increment&lt;/button&gt;
      &lt;/div&gt;
    &lt;/&gt;
  )
}
</code></pre>
<h2>実際に書いてみる</h2>
<p>仕様ライブラリ: Jest, react-testing-library</p>
<p><strong>テスト内容</strong></p>
<ul>
<li>初期表示はNumber: 0</li>
<li>Increamentボタンを押すと数字が1つ増える</li>
</ul>
<pre><code class="language-react">import { fireEvent, render, screen } from &quot;@testing-library/react&quot;
import { Counter } from &quot;./&quot;

describe(&quot;Counter&quot;, () =&gt; {
  test(&quot;render&quot;, () =&gt; {
    render(&lt;Counter /&gt;)
    expect(screen.getByText('Number: 0')).toBeInTheDocument();
  })
  test(&quot;increment&quot;, () =&gt; {
    render(&lt;Counter /&gt;)
    const button = screen.getByText(&quot;Increment&quot;)
    fireEvent.click(button)
    screen.getByText(&quot;Number: 1&quot;)
  })
})
</code></pre>
<p>なるほどこれは仕様書になる...!</p>
<h2>Reactで優先的に書くべきテスト</h2>
<ul>
<li>ロジックがあるor少し複雑なUIコンポーネントのIntegration Test</li>
<li>Custom Hooksなどの切り出されたロジックのUnit Test</li>
</ul>
<p>ロジックが複雑でバグが出やすそう...<br>
ここが壊れたらヤバい！不安で夜も眠れない...<br>
そんな不安を解消してくれそうな部分からテストを書きましょう。</p>
<h1>はじめてテストをやってみて</h1>
<h2>感想・気づき</h2>
<ul>
<li>サーバーサイドのテストとはまた違った難しさがある</li>
<li>Integration Testをしっかり書けば仕様書になる</li>
<li>E2EテストのCypressも触ってみたい</li>
</ul>


#QA

Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

フロントエンドテストのはじめかた