Fukabori.fm #13がピンポイント過ぎたので記事にしてみた
タイトルの通り、Fukabori.fmを何の気なしに拝聴したところ、 #13のt_wadaさんの回がドストライクだったため、備忘録として記事にしてみました。
こちらが該当のエピソードです。 fukabori.fm
視聴したきっかけ
最近web系のモダンな現場に参画し始めたため、テストコードを書くことが日常的になってきました。 その際によく悩むのが、
- どういう観点でテストコードを書けば良いのか
- このメソッドはテストすべき？
- 分離性の高いメソッド、クラスの分け方
- どこまでモックで、どこまで実際のモジュールにすべきか
- フロントのテストってあまり聞かないけどやらないの？
といった感じです。 業務中に隙を見てQiitaの記事をさらってみますが、ピンとこない...悶々としていたところでした。
注意点
以降にて印象に残った内容を記載しますが、以下注意点です。
- ペアプロ部分も参考になりましたが、近い将来に実践することが考えにくかったので、 当記事では記載を割愛してます。
どこまでをモック化するか
モック作成のメリット
- 動作の軽量化
- 分離性は高まる
- テスト実行時間 減 → 開発スピード 増
モック作成のデメリット
- 結局モックなので理想の振る舞いであり本物ではない
- コードの文量や重複がふえる
- 本物のモジュールで繋げたテストよりも信頼性の低下
t_wadaさん流派
自分の開発環境にインストールできるかどうか
- redisはインストールできるので本物で
- 外部APIはモック作成
プライベート関数はテストしない
それでもテスト書きたいってことは不安がある
→ プライベートではなくパブリックな責務を持ってしまっている
(※メソッドの責務分割がイマイチわかってない、キャッチアップ要)
このようにリファクタリングのチャンスとなる
ブラックボックステスト？ホワイトボックステスト？
→ ブラック 仕様・振る舞いの観点からテスト書く
不具合には二種類ある
- 本人がミスと気づける不具合 → テストコードで潰せる
- 思い違いやIFミスによる本人が気付けない不具合
カバレッジを検収条件にしない
カバレッジの活用方法 → 一定期間の推移で見る
- 減っている場合：新規コードのテスト書いてない
- 増えている場合：新規＋既存のテストが書けている
フロントエンドのテストコード
UI/UXのためフロントを細かく修正するのは大事
見た目を変えるのを邪魔しないようなテストに
その他
エンジニア同士の横のつながりを全社的にサポートする。 部署内で孤立してしまうと部署間の横展開できず、エンジニアが辞めてしまう。
視聴の所感
自分はケースバイケースだなぁ〜で回答を終わらせてしまうことが多々あります。 でもそれでは聞き手が得られるものがない。 t_wadaさんは流派の説明を踏まえ、「自分ならどうするか」を持っているため非常に参考になると感じました。 「自分はどういう理由でこう思う」が説明できることをインプットのゴールにしようかと思います。
次やること
- メソッドやクラスの責務について理解
→ TDD本やリファクタリング本などで体系的に勉強
