クラス設計の観点はテストが書きやすいかだけで良いと思う。以下のその理由を書いていく。
テストコードが無い洗練された設計よりも、汚いコードでもテストコードがあった方が良い
よくテストコードが無いのにこのコードがキレイだと言う人もいるが、これってすごく主観的だよなと思う。実際にキレイだったとしても、後の人が意図を汲み取れず変な建て増しをすることもあるし、その当時は最適だったのかもしれないが、後にアーキテクチャの方針転換から微妙になったりすることはある。
またコードがキレイかの判断軸はかなりエンジニアの力量にも左右されるので判断が難しい。自分は関数型に影響されているので、副作用の無いコードに対して良いと判断しがちであるが、そもそも関数型に対して興味が無ければそういう判断にはならない。他にもDDDをよく勉強している人は恐らくDDDの観点からこのコードはキレイかどうかを判断しがちである。
つまり、どのコードが保守性や拡張性があるというのはそれぞれのエンジニアのバックグラウンドにも影響されるので絶対的なものが存在しないし、あったとしても現場で統一するのは難しいと思う。
その点テストコードがあるかどうかというのはすごく分かりやすい。テストコードが無くてこのコードは良いか悪いかという判断は実際によく読まないと分からないが、テストコード有無は一発で分かる。また、テストコードが書きにくいコードというのは何かしら問題があるので、必然的にコードの質は担保される。
というよりも自分の中でDDDもClean Architectureも関数型言語を採用する理由も結局テストコードを書きやすくするかの手段のような気がしている。なぜかというとDDDを採用しているけど、テストコードが書きにくいというのはあまり成り立たない。
結局テストコードさえあれば多少の設計のミスはリカバリできるが、テストコードのない設計ミスを後から修復するのは難しいので最初から用意しておけば良い。
テスト導入を阻むもの
色々な現場を見てきたがテスト導入を阻むもの障害は９割以下である。
開発工数が余計にかかるからやりたくない
これは本当によく聞く。ただこのパターンはハッキリ言えばその本人のスキル不足である。実際にテストコードをよく書く人なら分かるがテストコードを書く時間は慣れればそこまで多くない。コードのキレイさよりも網羅性が重要であるため、例えばコードの共通化が必要ないからキレイにそこまで書く必要ない。
テストコードは書けるけど、開発工数がかかるからやりたくない人は経験上いなかった。単純に経験なくて自信が無いからやりたく無い人が多く、その理由を開発工数にしているだけである。そもそもテストコードを書くも含めて開発工数の見積もりをするわけで別に考えているのがそもそもおかしい。
この手のタイプに対して論理的にテストコードのメリットを話しても無駄であるし、論破したところで解決するわけでもない。 結局テストコードのメリットを言葉や文字で説明してもしょうがないので、地道に書くことを指導する。 テストコードはただの慣れなので量を書けば、後に質は担保されていく。だから初期は細かい指摘をするのではなく、ただ単純に書いてあることを褒める方が良い。
また実際のサービスではテストコード前提の設計になっていないため、そもそも適用しずらい可能性がある。そのため、すぐに実践するのが難しいかもしれない。なので、そういう時はハンズオンを開いて地道に簡単なコードで試すのが良いと思う。強制的にやるのであれば、実際に外部から人を招聘してやるのも良いと思う。
テストコードを重視する文化
とにかくテストコードをきっちり書きましょうという文化を作ることが大変だ。確かにまだサービスにユーザーがいない段階においてきっちり書くことに対しては否定的だ。ただし、利益を生み出すフェーズに入ったならばテスト主体の設計方針に切り替えた方が良い。
