Javaエンジニア、React+Firebaseでアプリを作る

趣味で作ったものいろいろ

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

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

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

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

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

ケース1

f:id:yucatio:20181226144733p:plain:w300

f:id:yucatio:20181226144750p:plain:w300

あると思います。

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

ケース2

f:id:yucatio:20181226145525p:plain:w300

f:id:yucatio:20181226145537p:plain:w300

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

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

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

f:id:yucatio:20181227085748p:plain:w350

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

f:id:yucatio:20181227085710p:plain:w350

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

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

f:id:yucatio:20181227085725p:plain:w350

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

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

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

yucatio.hatenablog.com

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

テスト駆動開発 [ Kent Beck ]
価格:3024円(税込、送料無料) (2018/12/26時点)