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

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

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

前回に引き続き今回は第2位です。前回の記事はこちら↓

yucatio.hatenablog.com

テストを書くのが嫌になる瞬間 第2位 : 開発中に仕様が変わったとき

今回も11コマ漫画でお送りします。

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

f:id:yucatio:20181222230305p:plain:w300

f:id:yucatio:20181228162835p:plain:w300

f:id:yucatio:20181222230336p:plain:w300

あるあるではないでしょうか。実際にはもっとぐだぐだ説明してます。 (ちなみにCさんは仕様を決めたり他部署とのやりとりをしたりスケジュールを管理したりする役割の人です。)

コードの変更が数行でもテストの変更や追加が大幅になることがあります。特に1つのvalidationをするためのパラメータが3つや4つになってくると、単純に組み合わせぶんのテストをすると膨大な数になります。通常、全ての組み合わせぶんのテストをする必要はないので、どの組み合わせをテストするのか考えますが、これには時間が必要です。できているぶんのテストに追加しようと頑張りますが、大抵は1から作り直した方が早かったりします。 (ちなみに、すでに書いたテストを生かそうとして、テスト落ちたら期待値を書き換えるという手法をとると、期待値を検証せずに書き換えてミスに気づかないことが多いので絶対にやめとけ。)

ソースコードの変更が少ないので、プログラムを書く人以外にはテストの変更も少しであると思われるようです。毎回どうやったら分かってもらえるか苦心しています。

このように途中で仕様が追加されるのはプロジェクトの開始時にある程度予告されている(仕様が変わるかもと言われている)ことがほとんどですが、変わらないこともあるので進められるところまで進めてしまわなければなりません。

仕様が固まってから動きたいところですが、いろいろな部署が関わっている以上動かせるところは動かしてしまった方が良かったりするんですよね。理想的にはいかないものです。

こういうことが起こるので、TDDなどのテストを先に(または同時に)書く、という手法には、会社での開発には手が出しにくいと感じています。(個人での開発や少人数での開発には向くかもしれませんが)

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

yucatio.hatenablog.com

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

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