ソフトウェアのテストを書くのが嫌になる瞬間第1位

昔々、上級エンジニアのNさんは私に言いました。yucatioさん、テストはちゃんと書きましょう、と。時は流れ、チームにテストを書く習慣ができました。めでたしめでたし。テストを書けば変更の影響がすぐに分かるので安全にリファクタリングができます。

でもなぜでしょう、たまにもうテスト書くのは嫌だという気持ちに襲われるのは。そこでそんな気持ちになる瞬間をランキング形式にしました。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

テストを書くのが嫌になる瞬間第1位 : テストを通すために期待値が上書きされたとき

ちょっとタイトルがわかりにくいので、10コマ漫画でお送りします。

f:id:yucatio:20181220125009p:plain:w300

f:id:yucatio:20181220124821p:plain:w300

f:id:yucatio:20181220124835p:plain:w380

(実体験を基にしています。)

これには参りました。テストを書く目的の1つとして、デグレを防ぐというものがありますが、完全に無効化されました。テスト書くのは面倒だし時間もかかります。それでもテストを書くのは、将来的にコードが変更されても動作が変わらないことを保証するためです。しかし、期待値を実行した結果で書き換えられてしまっては保証も何もありません(泣)。

この時は元のテストコードを書いた人(Aさん)がレビューしたから気づいたものの、Aさんがいなかったらきっとそのままマージされていたことでしょう。テストコードはプロダクションコードよりも読むのが面倒なことが多いので、注意して見ててても見逃してしまうことがあるので。

分かってはいます、Bさんのような人はごく一部だということは。しかし一度でもこのようなことをされるとテストを書いている最中、”テストを書いていてもどうせ間違った結果で上書きされるのではないか”、”それならテストを書かない方が良いのではないか”という極端な思考になってしまいます。もうトラウマですね。