どうもえいやです。
最近の業務ではオンプレサーバからのGCP移行とか、負荷試験の対応とか、JVMのチューニングとか、観葉植物の手入れとか色々あるんですが、その辺は当たり前にやることをやってるだけで、ネタにできるほどのことも、書く時間もないので、今回はとてもいい加減な感じでテストの話をしようと思います。
雑談とか、日記とかポエムとかそういう類のものです。コード例もありません。内容の推敲も、事実の確認もないです。
普段ふわっと思ってることを書きます。
「テストは重要」と分かっている人は、それ以上の内容はないので読む必要はありません。最後の１行まで飛ばしてください。
以下、いつもの通りですが、なにもかもがいい加減なので、可能な限りスルーしてください。
さて、「テストを書きましょう」と、プロジェクトで話が出るとき、一体いつのフェーズからそれを言い出して、書き始めるのはいつなのか。また、言い出した理由はなんでしょうか。
もちろん、プロジェクト、チームによって違います。
弊社で僕が担当しているプロジェクト（のサーバサイド限定）で言えば、まず言い出す時期について、多くの場合かなり遅めの段階で出ます。
モノが出来上がって、リリースして、稼働して、バグがちらほら出始めてから、くらいですかね。言い始めるのは僕で、言わないと永遠にテストが書かれることはないでしょう。言っても書かれるとは限らないけど。
ただし、その時点までにテストが全くないわけではなく、実装者が不安を感じるシーンではテストが書かれている部分もあります。その前提として、プロジェクトのコードが書かれ始める前に、テストフレームワークの選定や、多少個々人の趣味によりますが、テストの手法の検討も大体済んでいます（いるよね？）。
テストの話をすると、かなりガミガミ言ってくる人も多いので、TDDでやらなきゃとかテストファースト当然とか思う人も多いと思います。それらの手法にメリットがあることも事実で、デメリットなどない、と豪語する人もいるでしょう。
では、「テストを書きましょう」と本格的な指示が出るのが遅いことを以て、このプロジェクトはダメなプロジェクトでしょうか。
そのこと判断するまえに、「テストを書きましょう」と言い出す理由について考えてみましょう。
もちろん、限られたリソースを割いて「テストを書きましょう」というからには、テストの効果に期待しているわけです。
テストの効果は一般的に言われていることでは、１）「バグを検出し、品質を高める」ということが主なところでしょう。テストを実行可能なコードとしておくことで、変更都度の確認も楽にできます。
さらに、BDD形式のテストコードについてよく言われることでですが、２）「仕様のコード化」という効果もあります。仕様書やコメントは簡単に嘘をつきますが、実行可能な形式のテストコードは、少なくとも動作については嘘をつきません。
それに加えて、これは一般的にどう言われているのかわかりませんが、個人的には実装者に対しての３）「実装コードへの理解度を高める」学習効果もテストを書く上での重要な効果だと考えています。
この学習効果には、実装者が頭の中やサンドボックス、実コードへの試しの実装など、実装の途中で大体行っているような「一旦書いてみる」コードの正確度を高め。試行錯誤の回数を減らし、ひいては生産性を向上させる効果があります。
また、学習効果は品質にも影響があると想定されますが、学習進度が高い実装者であってもバグを組み込むことが往々にして存在するという経験則から、学習効果と品質の相関はこの際無視します。
学習効果の性質として、学習効果による生産性の向上は、あるプロジェクトの中で必要十分となる内容に限定すると、一定で頭打ちになります。
翻って、上述のテストの時期が遅いプロジェクトにおいて、１～３の効果がどれほど期待できるのかについて考えることで「テストを書きましょう」の指示が遅すぎるのかを判断してみましょう。
情報の後出しになりますが、このプロジェクトの性質として、次のようなことが言えます。
- 品質と密接な関係があるプログラムの複雑度について、初期リリース時点では可能な限り低く抑えた設計を行っている。仕様が複雑であっても、サーバサイドのプログラムの複雑度に寄与しない。
- リリース初期段階では、仮に停止していたとしても、売り上げ的な意味での機会損失につながらず、利用者もほとんどいない非クリティカルなサービス。かつ、全て自社サービス。
- 仕様について、リリース後に見直されることがなく消失したり、同じ名前で呼ぶ全く違う存在になったりすることがほとんど。
- 十分に学習済みのフレームワークを用いて、学習済みの手法を用いて、学習済みのチームメンバーのみで初期リリースまで行う。
以上の点で、
- １）について、高品質がまるで求められてない。
- ２）について、リリース初期段階の仕様を見直すことはほどんどない。
- ３）について、メンバーの学習進度は頭打ちになっているため、テストコードによる学習が生産性の向上につながりにくい。
のがプロジェクトの初期の段階です。なので、この段階でリソースを割いてテストを積極的に記述しようという号令をしたところで効果が低いのです。こういうプロジェクト、わりとどこにでもあるんじゃないでしょうか。
もちろん、利用者が増えることでプロジェクトが長期化したり仕様が安定化してきたりしてきて、コードに手を入れる必要が出てきたりすれば、要所から順にテストが導入されていきます（理想的には）。
利用者が存在しない限りバグが見つかることはほぼないので、前述の「バグがちらほら」がその合図だったりします。また、この時点以降でテストの保証するコードの範囲がある一定を下回ると、プロジェクトは紛れもなくダメになります（現に下回ってしまうことも常態化しているんだけど）。
以上の点を踏まえて、このプロジェクトはダメなプロジェクトでしょうか。ということを判断すると、たぶん「どちらとも言えない」か「どちらとも言える」ということだと思います。
個人的には、後からテストによって保証されたであろう品質や仕様のコード化がリカバリされる仕組みがない限りはダメだろうなぁと思っています。
ダメじゃない、と言いそうな感じで話を進めてきてなんですが、まぁダメですね。
単純にリソースの増加と無駄なリソースの投資を削減することなどが必要なんですが、まともなやる気に溢れるテストエンジニアかクオリティエンジニアの出現が求められます。
そういうわけで、プロジェクト進行と品質設計がちゃんとできるエンジニアを募集しています。
