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

ソフトウェアのテストを書くのが嫌になる瞬間、今回は第3位です。

テストを書くのが嫌になる瞬間 第3位 : コードもテストも間違っているのをみたとき

今回は7コマ漫画2本でお送りします。

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

ケース1

あると思います。

人間だからミスはします。レビューに出す時点でバグがないことを求めてもしょうがないです。 ただ、直す手間が2重にかかることを考えると悲しい気持ちになります。

ケース2

ないと思います。実際にあった話ですが(コード間違っていて項目Fが出力されていなかった)。

テストケース作成の理想と現実

理想としては、テストもコードも仕様から作成するのが望ましいのです。

しかし、しばしばコードからテストケースの期待値を作成する例が見られます。

1人の人間がコードとテストを作成すると、仕様を勘違いしたままコードとテストを作成してしまうケースが発生しやすいです。コードを書いた後にテストを書くなら、もう一度新たな気持ちで仕様を読んでほしいですが、それが難しいことは想像に難くないです。

ところでTDDはこうだと思うのですが、

仕様からテストを作成する時に仕様を勘違いしてしまったらその勘違いに気づくのは結構後のフェーズだと思うのですがどうしているのでしょうか。

TDDは個人開発(仕様を作る人とテスト書く人が同一人物)か、ビジネスの仕様に左右されない部分(共通で使用される関数など)をテストする時に有用だとは思いますが、仕様を作る人とテストを書く人が別の場合、バグを防ぐという目的の達成はあまり期待しないほうがよい気がします。TDDを職場でやったことがないので想像ですが。

第3位は以上です。その他のソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/26時点) 楽天で購入