104
56

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

テストを書くのはエンジニアとしてのプライドを保つために必要という考え

Posted at

はじめに

テストは絶対書くべきだ!と思っていて、ここ数年は当たり前のようにカバレッジ100%でプログラムを書いてきたこともあり、テストの重要性について考えたこともありませんでした。最近、テストを導入するか否かの話し合いがあり、個人としては「絶対書くべきだ!」と思いつつも、非エンジニアの人と話すと不要という考え方も一理あるのではと思うことがあります。ただ、個人的にはテストを書かないことに対し、相当な嫌悪感があり、それ自体が大きなストレスとなっていることも事実で、このストレスは、品質低下を危惧しているのか、それともなんなのか考えてみたら、私なりの答えが出たので経験を踏まえて書きます。つまり、ポエムです。

テスト書くメリット

テストを書くメリットはリグレッションテストの品質が一定に保たれることだと思います。経験上、バグは修正した箇所でなく、修正したことによって影響した他の箇所で発生することが多い傾向にあります。これを抑えるために、影響ある機能が正しく動作することのテスト、つまりリグレッションテストが必要となります。リグレッションテスト自体は手動、自動、どちらでも実現可能でありますが、手動ではアプリケーションの大きさによってテストケース数が比例するのでコスト増えます。また、人の入れ替えが発生し、アプリケーションの知見不足になり、リグレッションテスト自体の品質が担保出来なくなる恐れなど様々な問題があることも事実です。テスト書くとコスト掛かるけど最終的にペイできるよって内容でメリットを語ることが多いと思いますが、一番のリスクはコストでなく、リグレッションテストの品質低下によってテストすべきところがテストされてないことです。テストを書けば、機械的に一定の精度でテスト出来ますし、仕様変更したらテストが必ず落ちるので、テスト自体のメンテを継続して行われやすいはずです。リグレッションテストが形骸化しにくくなることで、一定の品質が保たれ、結果的にアプリケーション品質が向上するのがテストを書くメリットだと考えました。

テストコードが拒まれる何か

テストを書くことによるデメリットはコスト面ぐらいで、そのコストもいずれペイできるのだからデメリットはなさそうですが、どの会社にも必ずテストコードを拒まれる何かが存在するはずです。

工数がかかる

おそらく一番多い理由はこれではないでしょうか。実は工数がかかるというのは嘘で、中規模アプリでも自動テストのケースが1000を超えることがザラなので、修正毎に大量のケースを手動でこなすほうが遥かに工数がかかります。人間は優秀で、影響のありそうな範囲をテストすれば良いという判断が可能なので、テストケースを絞って品質を担保出来るからテストを書くよりも工数が減らせる可能性が高いという選択が取れるというのが正しいはずです。また、学習コストが高いので、知見者以外が見積るとどうしても工数が上がってしまいます。

導入効果がわからない

「工数かかるのはわかったけど、見合った導入効果は見込めるの?」

この理由も多いのではないでしょうか。t_wadaさんの登壇資料を穴が開くまで読み、どうにかテストを導入出来ないか交渉したエンジニアは多いのではないでしょうか。私もその一人です。ただ、現実問題、非エンジニアの人にこの資料を見せても説得出来ないことが多いです。登壇資料が誤った情報を発信しているのではなく、悲しいことにエンジニアの意見を信じてもらえない、信頼関係にあることだと思います。

テストを書きたい! vs 書きたくない!

これはエンジニア間で起こります。様々なテストに対する記事を見ると「スキル不足だ!」と書いてあったりしますが、実際は慣れの問題です。エンジニアとして、テストを書くことにデメリットはほぼないと思っているので、ここはプライドを捨てて少しずつ慣れていってほしいなと思います。私も数年前まで書けないから書きたくない!派だったのですが、優秀なエンジニアに出会い、1から丁寧に教えてもらったおかげでテストを書きたい派になりました。

テストを書くべし!の一択か

もちろん書くに越したことはありませんが、工数がかかる、導入効果が不明なのは一理あります。実際に私が開発した個人サービスではテストを書いていません。個人サービスにテストは不要とは言いませんが、書く時間の確保やモチベーションがないのでテストを書いても利益はないと思っています。とあるベンチャーの情報漏洩の記事を読むと確実にテストを書いてなかっただろうと思いますし、完璧な品質を求めなくとも利益がついてくる場合はそちらを優先すべきだと思います。つまり、テストは利益がどれだけあるか、被害がどれだけ大きいかによって判断するべきと思っています。ここで、テストを書いたほうがスピードが早いと思っている人は優秀な数少ないエンジニアです。

結局は何のためにテストを書くのか

バグは信頼をなくします。さらに修正した箇所ではないところにバグが発生したらエンジニアとしてのスキルが疑われ、説明も難しいので非エンジニアは嫌悪感を増すばかりでしょう。信頼を得られない=軽視されていると思うので、エンジニアのプライドを保つことが難しくなり、最悪の場合、負債の改修するだけのエンジニアとなる可能性もあります。プライドなんかくだらないかもしれませんが、エンジニアは事業成長に大きく貢献してますし第一線で活躍するためには必要なものです。自ら信頼を落とす方向に持ってく必要はありませんし、スキルも向上するのでテストは書くべきだと思います。なぜテストを書くのかといろんなソースを調べ、書くべき理由を探しましたが、一番は信頼を得てエンジニアとしての能力、地位を向上したいという情熱の部分だったのかもしれません。

104
56
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
104
56

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?