ソフトウェア開発者の7つの誤り その1

• 私のコードは動く

• 私のコードは常に機能する

• 私のコードは規模に関係なく動く

• ユーザーの不正入力がシステムを壊したのは私のせいではない

• 後でリファクタリングしよう

• ただの設定変更だ

• それは私の分野ではない

私のコードは動く

自分がコードを書いた直後は確かに動くでしょう
でもプログラムはしばらく動き続けるものであり、他の人がいじっても引き続き動き続ける保証はありません

だからテストを書くのです
自分がコードに修正を入れても他の人がいじってもプログラムが正しい動作をしていることを保証するために、テストを書きましょう

でもテストは大抵プログラム完成のためにやらなければいけない作業の一つであり、嬉々としてやる人はいないでしょう
次のような言い訳がよく聞かれます

• 簡単なプログラムだからテストは不要

  • 今はそうかもしれませんが、ずっとそうである保証はありませんし、「簡単」というのも主観的なものです

• 非常に複雑なプログラムだからテストできない

  • そもそもそんな複雑なプログラムなことが問題であり、設計からやり直しましょう

• 手動テストは行って自分のPCでは動いている

  • 自動テストの方が品質を担保できます

• 次のQAの工程でテストされる

  • QAテストでの手戻りはかなり非効率です

• 今はテストする時間がない

  • 今このタイミングでは30分節約できても、この後リリースまでに数時間のロスを発生させるでしょう

• 私のコードは完璧なのでテストの必要はない

  • 馬鹿を言え！

テストの存在そのものは大事ですが、加えてどんなテストをするかも大事です
よいテストケースを考えるためにプロダクトマネージャーやエンドユーザーと会話しましょう

また「テストの劣化」にも注意しましょう
私が書いたテストは完璧であっても、仕様変更により別の開発者がテストを動かすと失敗することになります
そのときにその開発者がテストを一部無効にしてしまうと、崩壊が始まります
割れ窓理論よろしく追加の仕様変更が入るにつれてどんどんテストが無効かされていき、ついにはほとんど動かないテストになってしまうのです

テストをしましょう！