PL/SQLでUnit Test継続中

今日もせっせとテストを書いていた。
今テストしているのは他システムとやり取りする処理。

  1. その処理は他システムに渡すデータをCSV形式で作成する。
  2. このCSVPL/SQLで実装したプログラムと定義データに従って作成される。
  3. CSV形式を他システムに合うように変換するライブラリがある。しかし、その変換結果は他システムとつながないと見ることができない。

で、現時点ではその、他システムは完成していない。
さあ、ここで問題。他システムが完成するまでテストは保留する?
当然、俺はしない。
だって、他システムと結合した時に不具合が出た場合に原因がプログラムなのか、定義データの不備か、他システムなのかすぐには分からない。
ということで、期待通りのCSVデータが作成されるかを確認するテストを書いている。
このCSVはデータ項目が150個ぐらいあり、期待データを作成するのは結構手間だった。
それでも作成した甲斐はあって、今日だけで数箇所のプログラム上のバグと定義データミスを発見、修正できた。


試しに既設担当者に以前はどうやってテストしていたのか聞いてみた。
そうしたら「他システムが完成してからテストしてました」とのこと。
「だって、二度手間じゃないですか」とのこと。
う〜む、そう思っちゃうか。
「でも、期待通りのCSVが作成されるかテストしておいたら他システムとの結合テストに安心して取り組めるでしょ?」と言ったら、
「それもそうかも知れませんが。ま、きまぶ〜さんのお好きなようにやってください」とのことで、どうでもいいという感じだった。
TDDやxUnitが一般になかなか広まらない現状を目の当たりにしたって感じだ。
おそらく根底に「テストは面倒」という思いがあるのだろう。
確かに手でしこしこやっていたらとんでもなく面倒だし俺だってやる気にならん。
でも、今はxUnitがある・・・といってもテストコードを書くことすら面倒と思ってしまうのだろう、普通の人は。
そういう人にこそWorking Effectively With Legacy Codeを読んでもらいたいが、そういう人ほどこんな本は読まないだろう。
先日参加した読書会だって参加者は明らかにテストばりばり書いていそうな人ばかりだったもん。


いくら口頭でテスト書くことのメリットを訴えても理解してもらえないんだよね。
サンプルを見せたとしてもサンプルはたいてい簡単なやつなので、「こんな簡単のやつのためにわざわざテスト書くんですか?」と言われるのがオチ。
テスト書いていると確実にストレスが減るんだけどね。
テストなしの開発はWorking Effectively With Legacy Codeにあるようにまさに"Edit and Pray"って感じだけど、テストがあると"Edit and Test and Peace"って感じ。