自動テストを書くべきだということに異を唱える人は居ないと思うが、実際の現場ではあれこれと理由をつけて省略されがちだ。あれこれと言っても理由はひっくるめると一つで「コスト」だ。そう、テストを書くのはコストが高い。本当だろうか。
コストが高いとは言いつつ、何故かテスティング・トロフィーの両端はそこそこ頑張っていたりする。型検査とかリントは当たり前のように入れている現場が多いし、一気通貫でテストしたいときは Playwright で E2E テストを書く。あとは申し訳程度にユーティリティ関数にユニットテストが書かれている。しかし、最も重要とされるトロフィーの真ん中あたりはなかなかテストが増えなかったりする。
なぜそこにテストを書かないのか。仕事なので「コストが高いから」と答えるが、「腰が重いから」というのが本音である。じゃあ何故そんなに腰が重いのかというと、個人的な感覚では「どう書けば良いのかパッとイメージが出来ないから」というのが大きい。丁度いい粒度の美味しいテストは、モックなどを駆使しないとテストが出来ず、クリエイティブな思考を要求されることが多い。もちろん、大抵のテストライブラリはモックの仕組みを備えているので簡単なものならすぐに書けるのだが、コードベースの規模が大きくなるにつれて一筋縄ではいかなくなってくる。きちんと吟味する前から漠然と「面倒そう」と想像して手を止めてしまうのだ。
腰が重い一つの理由は「先人がいないから」である。既に誰かが同じようなことをするテストを書いていればそれを真似することが出来る。最悪コピペして変数名などを書き換えれば終わる。しかし、過去に誰も似たようなコードを書いていなければどういう書き方をすればテストできるのか分からない、まさにフロンティアである。しかし、そこで立ちすくまずに新たな領域を「開拓」していきたい。一度そこで苦労して書いておけば、次に同じようなテストが必要なときはそれを参考にすればいいし、他のメンバーも真似してすぐに書き始めることが出来る。
腰が重いもう一つの理由は「慣れていないから」である。当たり前だが書けば書くほど慣れて速く書けるようになる。そして書けたことが自信につながって、次の時も「きっとすぐに書けるだろう」と楽な気持ちでテスト実装に入ることが出来る。思い返せば、最初に自動テストを学んだときは「1+1=2」すら大仕事だった。「足し算のサンプルは動いたが...実際の関数をこれでどうテストする？」という気持ちになったりもした。しかしそこは既にクリアしたからユーティリティ関数などはしっかりテストが書けているのだ。
十分に「開拓」された環境で「慣れ」た人が書けば、テストを書くコストはそこまで高くない。機能を実装したついでに同じブランチにテストを含めてマージできる。そこで書いたことによってまた慣れるので次はもっと書くのが速くなるという好循環も生まれる。大げさにしてはいけない。「テスト増量プロジェクト」とかではなく、日常の「当たり前」の作業としてシュッとやるのがクールだ。２人の開発者がいて、片方の人が機能を実装する間に、もう片方の人は同じ時間でテストもセットで実装していた、ということは良くある。言うまでもなく後者を目指したいし、そういう人が一人でも増えるように開拓を続けていきたい。
