良いテストコード、と言われて思い浮かぶ要素はいくつかあるだろう。
- 過度に DRY になっていない
- 上から下に読み下せる
- 仕様を網羅している
- テストデータが過不足なく当該セクションで作られている
など。
たまたま良いテストコードについて議論する機会があったのだが、DRY 具合について話していたとき
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方 | ログミーBusiness
のようなリンクを見せ説明したが僕のいわんとすることがあまり伝わらなかった。そして相手が重要視していることも正直なところあまり理解できなかった。 価値観が違うのだろうということは話していて感じていたが、どうしてこういう違いが生まれるのだろうということを疑問に思った。「育ってきた環境が違うから」とは思うものの、より本質的に理解するにはもう少し何かが必要だなと感じ考えていた。
僕はテストを（特にユニットテストを）きれいな設計・実装を助ける道具だと捉えていて、そういう世界を実現するために使っている。依存関係を正常に切り出し、インターフェースを整え、ケースを整理しデバッグするための手段の一つだと捉えている。一方、おそらく議論した方はあまりテストを書くのが得意でないか、もしくは実装は開発環境で確認しすべて実装が終わったあとに品質のためある種の義務として書くものというように捉えているように見えた。
これでは良いテストについての価値観が違うのは当然で、どっちが良いというわけでなく使う道具の目的が違うんだからそれに求めるものや理想が異なるのは当然のことだろうと腹落ちした。（もちろんテストを使いこなすメリットは大きいとは思うが、色々な開発方法がありバリューを出しやすい方法を採用すれば良いと思うのでその是非はここでは問題にしていない。）
僕が PC に求めるものと営業の方が PC に求めるものは違うだろうし、趣味ランナーの僕がランニングシューズに求めるものとプロランナーがシューズに求めるものは違うだろう。
どっちが良いとか悪いではなく、そういうことなのである。
