フロントエンドでTDDを実践する（理論編） - Qiita

この記事は リクルートライフスタイル Advent Calendar 2018 8日目の記事です。 2018/12/10更新：続編で フロントエンドでTDDを実践する（react-testing-libraryを使った実践編）を書きました。 はじめに 自分のフロントエンドチームでは、TDDでの開発フローを実施することでフロントエンド開発の課題に向き合っていきます。 今回は、一般的に難しいとされるフロントエンドでのテストについて、どんな方針でテストを書けばいいかについて書いてみたいと思います。 フロントエンド開発の課題 プロジェクトによりますが、テストに関連するものでは以下のようなものが挙げられます。 実装する仕様について、プロジェクト内でどう認識合わせするか？ 開発工程のリライアビリティをどう担保するか？ テストの精度、粒度をどう考えるか？（クロスブラウザ、ユーザーの操作等の副作用、コスト

[Keisuke69]

react testing libraryってどんな感じかな

[carolina04]

各Integration Testのケースを束ねるとアプリケーションの機能仕様ドキュメントにもなります。大規模開発の場合はプロジェクト内でエビデンスとして共有することもできます

[RabbitBit]

The Testing Trophy。

[yarumato]

“テスティングトロフィーはテストピラミッドに似た概念ですが、各種テストのコスト高さ（実行速度、開発/保守工数）に加えて、各テストの効果（どれほど大きな問題を解決できるか）を示した図”

[programmablekinoko]

なるほど

[masa8aurum]

>ロジックを持った単一モジュールにはユニットテストを書き、それ以外の機能仕様についてはインテグレーションテストでカバーする

[cuttoff19]

ユニットテストの勘所と具体例とか

[castaneai]

“ロジックを持った単一モジュールにはユニットテストを書き、それ以外の機能仕様についてはインテグレーションテストでカバーする という方針をおすすめします”

[akulog]

"個人的には、 ロジックを持った単一モジュールにはユニットテストを書き、それ以外の機能仕様についてはインテグレーションテストでカバーする という方針をおすすめします。"

[yug1224]

画面描画が絡んだりフレームワーク等が担当する部分の UT は難しいのでブラックボックスにし、 UT ではロジック部分だけを確認、各モジュールを結合した後に IT で全体の動作を確認するって感じ。