X(Twitter) Zenn GitHub RSS 共有

テスト

作成日時：2024-08-01以前
更新日時：2024-08-29

定義

単体と結合の分類は曖昧。現場による。
品質保証できていればなんでもいい。
モック使わずに上位モジュールを呼んで、下位モジュールの網羅をするとか。

いつものは1画面を単一コンポーネントと捉えて試験する = 単体試験なんだろうなと
「別画面の操作が別画面で出る内容に反映されていること」はE2Eっぽい。結合試験と言われたけど。

単体テスト

自動化

E2Eの量が多くなるのはデメリット。
主に実行速度とコードのメンテ。

自動テストが無い現場ではまずE2Eを作成。
その状態だとE2E塗れになる。
徐々に単体テストに移行し、E2EはE2Eでしか検知できない試験のみを行う。

自動テストが無いならば

まず手動テストをE2Eテストに置き換える。
E2Eテストならソースがぐちゃぐちゃでも書けるから。

E2Eレベルで振る舞いが変更されていないことを確認しつつ、リファクタリング。
テストコードが書きやすい構造になったら、xUnitを書く。

E2EとxUnitで重複するものがあるならば、E2Eを削っていく。
E2EはあくまでE2Eでしか検知できないテストケースのみを実施すべき。

そうしてテストピラミッドを作る。

参考文献：テスト自動化実践ガイド

テスト手法

スナップショットテスト

UIが変更されていないかを確認する。
スナップショット(UIの構造情報、DOMやJSON)を比較する。
コンポーネント単位。

ビジュアルレグレッションテスト(VRT)

UIが変更されていないかを確認する。
スクリーンショットを比較する。
画面単位。

スナップショットテストとVRTの違い

前者は構造の比較。
後者は見た目の比較。

ステートテスト

テスト対象のコードが正しい結果を返すかどうかを確認すること。
ステートテスト VS インタラクションテスト｜くぼぴー

インタラクションテスト

テスト対象のコードが特定のメソッドを正しく呼び出すかどうかを検証すること。
※ステートテストのリンクを参照。

スモークテスト

探索的テスト

ハッピーパステスト

モンキーテスト

負荷テスト

セキュリティテスト

フロント

シフトレフトの考え方

V字モデルの左側でもテスト(レビュー)する。

顧客に画面のプロトタイプを渡すとか。
→受け入れ時の手戻りを防ぐ。

Wモデル（だぶりゅーもでる）：情報システム用語事典 - ITmedia エンタープライズ

privateメソッドへのテスト

プライベートメソッドのテストは書かないもの？ - t-wadaのブログ

privateなメソッドは実装の詳細なのでテストすべきでは無い。
そのようなメソッドをテストしたい場合はクラスが責務を持ち過ぎているので分離すべき。

ケント・ベックの答え。
Should I Test Private Methods?

コンポーネントテスト

コンポーネントテストの手法と その効果を考える - Speaker Deck

vitestは動作環境を色々なものに切り替えられるらしい(p.19)
Playwrightとかも。

JUnitメモ

okhttp
jsonpath
@DisplayName

書籍