テストコードなしで開発するソフトウェアエンジニアは超絶優秀な人だ

公開日:2019-06-12
最終更新:2019-06-12

はじめに

主語の大きい釣り記事です。個人ブログに留めとく。ネガティブなきっかけでもテスト書くのはいいよねって記事になります。

テストコード。昔は正直コードに書こうがどうしようが、テストさえ出来てればいいよね?って考え方でした。でも自分でコード書く時は何かしらのテストコードを必ず書きます。
その理由は高品質を担保して~とか、リファクタリングが~とか大それた理由はなく、根本は「私の能力ではテストを書かないと制御できないから」というシンプルな理由です。
正直書かなくて済むなら書きたくないです。めんどいので

そんな私がテストはいいぞ!じゃなくてテストないと無理!っていうネガティブな目線でテストについて書いてみたいと思います。

※私のいうテストコードの粒度は、TDDがっつりやってる方がやる粒度のテストではないのを謝っておきます。
 Clean ArchitectureのレイヤーレベルだったらUsecaseくらいかな。大枠のIFだけ書くくらい

テストを書かなかった頃

思っていたことはこんな感じ。

  1. 仕様を把握してメンテナンスが出来ていれば、問題があっても抑えられるよね!
  2. 評価工程さえしっかりしていれば、テストコードをガリガリ書かなくても品質は保証されるよね!
  3. 自分の書いたコードは自分が一番分かってる!コードレビューばっちり!だからテストコードは保険程度だよ!
  4. カバレッジ網羅の為に必要なものだよね?それもちゃんとテストすればいいよね!

どれもあるあるって話だと思いますし、タイトルに繋がるけどこういったことを勝手に実践できる超絶優秀エンジニアさんであれば、テストなんか書かなくとも完璧でしょう。
私はそんなキラキラエンジニアじゃないのでテストを書きざるを得ないのです。

何故テストを書くの?

仕様を把握してメンテナンスが出来ていればいいのでは?⇒仕様書たるものは多い方が良い。テストコードはより実装に近い仕様書

テストを書く大きな要因の一つ。それはテストコードが開発者のマスター仕様書になるからです。
私たちのコードはこのテストを通すことでコミット可能とします!って条件は、例えば納品チェックする顧客のような一つの仕様チェックポイントとなります。
しかもテストコードはソフトウェアの動作と直接紐づくので、詳細設計仕様書(word, excel)みたいな仕様書よりもより実装と紐づきますし、開発者もメンテナンスしやすい。

OSSのコードを見るならまずテストコードを読むのが近道なくらいです。

大元の仕様を把握すればコードまで想像つく頭のいい人ならそれでいいですが、凡人ではユーザー仕様はユーザー仕様、実装仕様はテストコードと段階を踏んでてここを見る!ってわかっているのがやりやすいです。

評価工程さえしっかりしていればいいよね?⇒テストはやればやるほどいい

超絶優秀なテスト設計が出来るエンジニアさんは、要件仕様からまるで脆弱性を突くように的確なテストケースを作ってくることもあります。
その道のプロというのはどこにでもいるものです。

もちろんそんな優秀な方が抑えているなら品質が保たれますが、人の優秀さを期待して作業すると自分が品質を制御できなくて運に任せることになります。
こうなると自分の仕事に懸念がぬぐえなくなり、何か不具合報告がある度にソースコードを確認してという、何度も家の戸締りを確認しに引き返すような無駄が発生します。
でもそれはしょうがないのです。なぜなら私は優秀じゃないから。

優秀な人ならそんな不安を持たずに完璧な仕事が出来るでしょうが、私のような凡人はその不安をぬぐい、平穏な日々を過ごすために基準を設ける必要があります。
平穏とテストコード、どちらを取ると自分が穏やかに過ごせるのかというのは大事なことだと思います。

コード理解やコードレビューがばっちりなら問題ない!⇒俺の目には狂いしかない

こういった懸念、不安、大きなバグというのはその人のスキルの問題だ!コーディングスキルが高い人なら問題ない!
とか
問題が漏れるのはプロセスの問題だ!抜け漏れがない体制を作るべきだ!
といった理論、わかります。ですよね、ミスの原因は人・チームにあるからそれを改善すればいいですよね!
…完璧な人・チームならいいと思いますけど、少なくとも自分や自分が関わったことのあるチームは100%ミスしないなんてことはなかったです。

まあ人はミスする生き物ですからね。これは皆さん同意していただけるかと思います。じゃあどうする?自己研磨、チーム改善もいいですが、それ以外にも楽な方法があるならやりましょうよ。
99%を99.9%にする以外に、他で10%を50%にすることは出来ます。テストを書けば他の10%部分を80%, 90%にすることが出来、他の要素との掛け算で質を上げることが出来ます。

特に人の目で介在する部分はどんなに精度を上げても凡人には限界があるので、俺の目以外のフィルターを増やしてあげると効果的じゃないかと思います。

カバレッジ網羅の為に必要なものだよね?⇒手動カバレッジめんどい…

この項は個人的に思ったことで、ちらほら記事も見かけた記憶があったので上げてみました。
たまにあります、カバレッジC0 100%にしないといけないとかいう要件の案件。あれベースのテストコード書いてないと凡人にはめっちゃめんどいんですよね。
(実際100%なんていらない)

このif文を通すためにgdbでステップ実行してinputを変えて~みたいなことを納品毎にしないといけない。もうテスト書いた方がはやくない?って話。

後実際ちゃんとインターフェースを切っていれば、そこに対してのテストを全ユースケースで書くだけでかなりのカバレッジ網羅できるんですよね。
Cのライブラリを書いてて感じました。ライブラリAPIの使用方法でテスト書いただけで、mallocエラーのような致命的エラー以外大抵網羅出来ます。それ以外があるってことは、何か無駄なことをしてる可能性もあります

というわけでこれは「テストといっても要所要所で抑えていれば、網羅性も出ますよ!」って話です。
感覚的には全関数に対してテストコードを書いてTDDするよりは、大きなIFレベルで振る舞い・ユースケース目線で潰すBDD(behavior driven development)くらいで十二分だと個人的には思ってもいます。

最後に

テストマンセー!じゃないけど結局必要なのでテストを書く人の所感をわーっとたしなめてみました。
TDDは苦手です。でもテストは書きます。
その理由は書かないとめんどいから。影響範囲を覚えてられないから。コード仕様を書き残したいから。
くらいの感じ。

色んな人もいるのね~っていう参考になれば嬉しいです。

備考

  • カバレッジ網羅は80%もあれば十分だよって記事があったのでリンク付け
  • 各要素でお絵かき
記事が少しでもいいなと思ったらクラップを送ってみよう!
58
+1
@dOpIa1PQNPi5jLrnの技術ブログ

よく一緒に読まれている記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる

技術ブログをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

技術ブログを開設する

Qrunchでアウトプットをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

Markdownで書ける

ログ機能でアウトプットを加速

デザインのカスタマイズが可能

技術ブログ開設

ここから先はアカウント(ブログ)開設が必要です

英数字4文字以上
.qrunch.io
英数字6文字以上
ログインする