2023/04/25 フロントエンドのテスト設計とアーキテクチャ
関連
テスト設計はユーザーとシステムにとって意味のある振る舞いを主体にしたい 本質的にステートフルなGUIのテストケースを事前に網羅するのは難しい 開発者視点で「自身の担当する責任範囲」が問題空間の境界上で意図通り振る舞うかのテストも書きたい 実装もある程度意識しないといけない
ロジックはhooksへ移動したとはいえhooksのテストはモックで自作自演になりがち
状況によってプレゼンテーションだけを切り離すとかはやるが、テスト目的で毎回やるわけではない
本当に意味のあるテストになっているかは疑問視している
ユーザーにとって意味のある振る舞いのテストになっているか？
その関数はコンポーネントに依存していないか？
そもそも設計の単位がデザイン上の問題空間の分割に依存する 正直ここが一番の変数
一つずつ方針を立てていく必要がある
自身が改修してコケたテストは本当に意味のあるテストになっているか？
必要性を見いだせないテストは生産性を下げる
チームの共通認識が持てなければメンテしなくなるので捨てられる
例えば
「このテスト、こういう風に実装をリファクタリングしたら消せそう」
「このテスト、こういう風にデザインを変えたら不要になりそう」
「あ、デザイン変えたら機能的にも実装的にもシンプルになりそう」
フロントエンドで顕在化する問題のほとんどは、フロントエンドの外にある
など考えてる間に、変数が多くて沼にハマる
仕様を学ぶためだったり、TDD的にフィードバックを得るための後から捨てても良いテスト 主張
ロジックを可視化してコラボレーションしようぜ！
関数のパラメータの敷居値を自動生成しようぜ！
以前のツイート
Zag: a11yに配慮したUIのFinite State Machine
Figmaからアクセシブルなコンポーネントが出力できて、かつ状態遷移が静的解析できる基盤になる可能性を秘めている @koushisa: ここまでくればtesting libraryとStorybookのスケルトンを出力できるはずで、UI開発はFigmaからポチポチすればよくなる @koushisa: UIの実装は任せてしまって、開発者はSpec定義とtesting libraryでその振る舞いを担保するのが主な仕事になる このページを書いたときのツイート
@koushisa: うーん、フロントエンドのテストの理想を追求してくとやっぱ形式手法に辿り着くな...これ現代も研究されてるのかな？運用するにはツールが整ってないように感じる →割と堅実に進んでいる
2023/10/20
フロントエンドでテストやアーキテクチャに拘りすぎるのは微妙
（ ちゃぶ台返し）
ユーザーのモチベーションと現状仕様を理解して、機能徹底的にシンプルにするよう働きかけるほうがROIは高い
フロントエンドでガチガチなテストが必要な機能は本当にユーザーにとって使いやすいUI/UXなのか？ 自分の関心はここにある。E2E寄りのテストを増やすためにはシンプルな機能を目指さねばならない
koushisa.iconの理想が詰まっていて、ちょうどいい塩梅
ここに賭ける価値はある
気になる
試してみたい
エンジニアからしたら、
「入れない理由がない」レベル
最大の難点はコストとビジネスサイドの理解
以下のような仕組みで、まず作る/試すを実践しつつビジネスを開発プロセスに巻き込む気概が必要 知識の差、考え方や文化の違いはあるので茨の道である
関連
それ以外の細かい部分はデザインの戦略に適した戦術を使う