「Fukabori.fm エピソード13 ゲスト：twadaさん」を聴いて（主にテストに関する話）
最近通勤中はエンジニア向けのPodcastをよく聞いているのだが、
上記Fukabori.fmのtwadaさんゲスト回が学びが多すぎて、メモ的に記録しておきたくなった。
こんな貴重なお話がフリーで聴けるなんて、本当にありがたいことだ。
※自分の言葉と分けるためにPodcast上の話は引用で記載しているが、
まんまPodcast内で話された言葉ではない。要約している。
『見られているだけでコードの質は高まる』
コードレビューがある=他人に見られているという意識ができるだけでコードの質は高まる。
なので、コードレビューのインフラに投資する。
ペアプログラミングの話から、コードレビューでも同様の効果はあるという話になって。
コードレビューは、導入してない状態からするとなった場合、費用対効果とかの話になっていきがちだなと感じていたが、コードレビューによって生まれる「意識」というのは盲点だった。
確かに後輩とか新人の方に、恥ずかしい・ダサいコードは見せられないなという気持ちはある・・・
『テストを書く場合、自PCにインストールできるものは本物を使い、できないものはモック／スタブを作る』
これもすごくスッキリした。
具体例でいうと、コード内でAWSのサービス、例えばS3などを使うというケースの場合、モック/スタブ化するのが良いというところなのかな。
自前のWebAPI等と絡むコードの場合、それは環境を用意できるので実物を使う、とか。
『プライベート関数はテストしない』
プライベート関数は、パブリック関数からテストできる。
プライベート関数は現状追認のテストになりがち。
リファクタリングを支えるテストにはならない。
プライベート関数、思いっきりテストしていた・・・
テストコードからはリフレクションで関数名を取得するので、
これはどうなんだろうと思いながらも・・・
ただ、言い訳としては関わっていたシステムがWindows Formのレガシーシステムで、パブリックからテストが困難なクラスが多く、
それでも機能追加を行っていかなければならないという状況で、
新規追加したプライベート関数はせめてテストしたい、という思いがあった。
が、今回「プライベート関数のテストは脆いテストになりやすい」というのを認識できた。
『UIのテストコードは書くけど、書きすぎない』
UI=Viewは変更が大きい部分。テストが失敗しやすい。
テストが失敗するからViewを変更したくないとう本末転倒な状態が生まれてしまう。
なので、よくやる方法としては、詳細なテストは書かない。ユーザーのシナリオレベルのテストを自動化＝CIで回していくようにする。
画面の構造が変わっても影響が少ない部分をテストする。
CIなどでスクショの変更前・変更後の差異を抽出して、それを人間が見て変わっている・変わっていないと判断するのも効果的。
画像の差分を取る技術は進化してきている。
ちょうど今の現場のASP.Netのシステムで、Selenium導入してUIテスト自動化できればなと考えていたところだったので、非常に参考になった。
画像の差分を取る話については、以前Google内のテストの本でも見たことある。
『カバレッジは絶対値ではなく傾きで見る』
カバレッジは進捗など何らかの管理道具にすると、うまく回らない。
カバレッジは絶対値ではなくCIなどで「傾き」をみて、チームの健全性を図る指標にするのがよい。
カバレッジが高い状態から低い状態に推移ししている場合、テストコードが書かれなくなってしまっているのかもしれない。
低い状態から高い状態に推移ししてるなら、新しいコードにもテストが書かれていると取れると解釈できる。
この話も今後ぜひ参考にしていきたいなと感じた。
昨年在籍した現場ではカバレッジ100%が達成基準だったけど、
単発的な納品なシステムだったのでまあそういう選択肢もあり得るのかな。
ある製品を継続して保守していく、となった場合はこの考え方が良いと思う。
