テストについてまず知っておきたい用語

なぜこの記事を書こうと思ったのか

フロントエンドエンジニアとしての経験が一年となり、いよいよ自動テストなどの知見も付けていきたいなぁと思っていたところ、
テストの中にも種類があったりでなかなか脳内に浸透せず、
ちょっとここで用語の整理を忘備録として残しておきたいと思います。

私の経験について

React　TypeScriptの経験が一年ほど。
ローカル環境での開発、実施経験はあるがデプロイやビルドに関する知見が無い。
テストに関しては想定ケースを考えてテストケースをエクセル上に書き出し、手動テストのみの実施経験。

なので、テストに関することのまとめとして今回記事を書いています。

それではよろしくお願いします。

そもそも何で自動テストが必要なんだ？という話。

・　テストコードを書くのは工数がかかる
・　テストに関することもそれなりの知見が必要になる

こういうところがあるのですが、それを差し引いてもテストコードがあることで、
作業におけるバグなどの手戻りも、発生しづらくなるということがあるみたい。
手動テストでも都度都度バグ見つけては直したりしてたけど、そういうのがもしかしたら減ってたのかな。

自動テストで防げる点、防げない点があるので、可読性の高いコードを書くとか、手動テストでの網羅性みたいなものを意識してあげてチームでケース考えて取り掛かるのが一番いいんじゃ無いかと思う。
もちろん使えたら便利だし、技術に関するニーズもあるのが現状。あとはテストってどんな種類があるのかってことを覚えておきたい。

テストは主に4種類なので下記について

• Static Test (静的テスト)
• Unit Test (単体テスト)
• Integration Test (結合テスト)
• End to End Test (E2Eテスト)

Static Test(静的テスト)

これはJSやReactでのTypeScriptでの実装最中に起こる型エラーなどが主なものになります。
変数名の書き間違い、型の不一致の可能性などを表示してくれるものですね。

他にもESLintやコードフォーマッタの「Prettier」なども、静的テストに含まれるそうです。
なのでローカル環境での開発をしながら検出されるエラーが、「静的テスト」という認識でいれば問題はなさそう。

Unit Test(単体テスト)

これはvitestやjestなどで扱われれる、ユーティリティ関数やカスタムフックなどの単体での動作確認をテストする際に行われるテストです。（期待値などを設定できる）
これらを使用する場合にテストコードの作成が必要があります。

Integration Test (結合テスト)

それぞれのコンポーネントや関数を組み合わせた時に機能が問題なく使用可能かどうかをチェックするテストのこと。
結合なので、「組み合わせて」使えるかどうかをチェックします。
testing-libraryが割と使われていますね。

End to End Test (E2Eテスト)

E2EテストはAPIやブラウザ等の環境でアプリケーションを開始、システム全体が正しく動くかをチェックします。
フロントエンドのエンドツーエンド（E2E）テストは、手動でテストケースを考え、それを自動化するためにスクリプトを書く必要があります。E2Eテストは、ユーザーが実際にアプリケーションを操作するシナリオをシミュレートするため、手動でのテストケースの設計が不可欠です。
大規模アプリケーションの場合は回帰テストの実施などが省略できるため、自動化実装が出来ると便利。（ただしこちらも工数がかかる）

Cypressなどのライブラリがあるみたいなんですが、もう少し学習は先かなぁ、　まずは小さくvitestかな。

補足

ステージング環境での手動テストは、結合テストの一部としてみなすこともできますが、通常はエンドツーエンドテストに分類される。

よく聞くけどよくわからない「パイプライン」ってなんだ？

A ソフトウェア開発やデプロイの一連操作のプロセスを自動化してくれるもの。

一連操作の例としては、ビルド→テスト→デプロイを自動的に実行してくれる。
各ステージは前のステージが成功した後にのみ実行され、失敗するとその時点で停止します。

この、パイプライン内の「テスト」に失敗したりする場合は、前述の通りでデプロイが行われず処理が停止する。

CI/CDって何？

CI/CDは、継続的インテグレーション（Continuous Integration）と継続的デリバリー（Continuous Delivery）または継続的デプロイメント（Continuous Deployment）の略。

継続的インテグレーション（CI: Continuous Integration）
**継続的インテグレーション（CI）**は、開発者がコードを頻繁にリポジトリに統合（マージ）するプラクティスです。このプラクティスの主な目的は、コードの変更を早期に検出し、統合時の問題を迅速に解決することです。

継続的デリバリー（CD: Continuous Delivery）
**継続的デリバリー（CD）**は、ソフトウェアを常にデプロイ可能な状態に保つプラクティスです。CIの後に続くプロセスで、リリースの自動化と承認を含みます。

つまり

何やら難しく書いてしまいましたが要するにあれです。
git-flowで管理してるリモートリポジトリ内のstgブランチやmainブランチに変更がかかった際に自動的にデプロイがかかる処理のことです。

最後に

アウトプット目的となってしまいましたが多少用語のイメージはつきやすいんじゃ無いかと思います。
知見をつけていきたいですね。
vitestを覚えたい。けど個人開発の小規模アプリだとユーティリティ関数そんなに使わないんだよなぁ。
ありがとうございました。