「プログラマーの情熱を奪わない開発プロセスとは？ 」記事へのコメント

まず疑うべきところ

[Anonymous Coward]

> テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。
まずこれから疑った方がいいと思うけど。
内容にもよるがテストを書くのが一番つらい。

Re:

[Anonymous Coward]

そうですか?
テストを定義できさえすればいいのでみんな割と遊んでいます。ガス抜きっていうか。
いやまぁ、かっこいいけれど速度がべらぼうに遅いとか、環境依存とか、困ったのを書いちゃうことはあるけど。
つらいっていうほど時間も食わないと思いますけどね。

# 俺のテストのカバレッジが100%行かないのはなぜだって言って、カバレッジ計測ソフトのソースコードから調べた奴もいた。

でもまぁ、テスト駆動っていい実践だと思いますよ。高レベルのアプリケーションを書くプロジェクトではとくに。
とりわけビジネスロジックの実装をするお仕事では威力が高い。

Re:

[Anonymous Coward]

作ってるシステムにもよると思いますが、自分が入ってるプロジェクトだと、
IOが関わるところ(DBへの読み書き)がメインだから自動テストは作りにくいんですよね。
スタブ作ると労力かかりすぎるし、IOを除いたテストしやすい形でコード書くと逆に分かりにくくなるし。

あと最上位のメソッド以外はリファクタリングを頻繁にするので、
その度にテストコード書き直すのはたぶんかなりのストレスになります。

もちろんコード変更したらテストはしますが、手動のテストで十分で、
自動テストに取り組むモチベーションがありません。
だからTDDについては本当にいいの？ともやもやしてます。

Re:まず疑うべきところ

[Stealth (5277)]

作ってるシステムにもよると思いますが、自分が入ってるプロジェクトだと、
IOが関わるところ(DBへの読み書き)がメインだから自動テストは作りにくいんですよね。
スタブ作ると労力かかりすぎるし、IOを除いたテストしやすい形でコード書くと逆に分かりにくくなるし。

この辺りなんですが、単体テストクラスごとに個別に DB を簡単に作成できるかどうかというのがポイントではないでしょうか。SetUp/TearDown で CREATE/DROP DATABASE していいかどうか、とか。
というか、こういう事ができて簡単にテスト用データを (テストごとにトランザクション作って) 突っ込めないと、まともな自動化テストとかやってられないと思うのですが。

単体テスト的な話で言うと、実行時間が格段に跳ね上がる (ひどいと数十の DB を一気に作りに行き、一気に削除する) とか、他の実装に依存したら単体じゃないだろとかツッコミどころは出てきますが。