SUGEEEEEEEEEEEE
今日、仕事で顧客と打ち合わせをしてきた。顧客と言ってシステム開発をしてる会社だけどね。
TDDの話を聞いてきた
以前、ウチの職場ではユニットテストツールを使うかどうかでモメたことがある（今日会ってきた顧客の別案件でユニットテストを使用することを推奨します、という要望があったのだ）。
で、今回おれが関わっている案件での単体テストをどのように実行するか？ という話で、当然ユニットテストを使っていますので、できれば使ってほしい、という話をきいた。
で、ガチで使っているっぽいので実際にどのような運用方法をしているかを聞いてきた。
基本的に、以下の成果物を製造フェーズでのアウトプットとしていて、それぞれを矢印の右側に書いたものを成果物として扱うようだ。
- プログラム設計書→製造したソースから出力した JavaDoc や RDoc のドキュメント
- プログラム→製造したソース
- 単体テスト（及び単体テスト仕様書）→ユニットテストコード（Junitや Runit のソース）
で、これらの作業を一括りにしてスケジューリングを行うらしい。つまり、プログラム設計書作成*1・プログラム・単体テスト込みで5日間、と言った具合である。
まぁ、ユニットテストを通していれば、不具合があればその場でプログラム修正が入るし、それに伴ってJavaDoc などの文章なども変化するであろう事はサルでもわかる事なので、明示的に2日でプログラム設計書を書いて2日でプログラムして〜なんて書けるわけが無い（つねにテストや製造が入り乱れるんだからね）。
更に話していると
担当の方はこういった「さすがにテスト駆動とまでは行かないけど、常に単体テストを通すように開発は進めてるよ」
さすがにテスト駆動とまでは行かないけど
テスト駆動！！！
ウチの職場では誰も発言しないであろう単語、そして発言したところで「で、テスト駆動って何？」「ただの無駄工数だろｗｗｗ」「テストを先に作るとかアリエナスｗｗｗ」と言われるでろう単語。
なんかもう、この単語を聞いただけでおれのテンションはMAX。っていうか、マジそっちに転職してEEEEEEEEEEEEEEEEEEEって思った。でもなぁ、その会社は地方にあるんだよなぁ(´Д`)
いやしかしね、こうやって開発している会社が確かにあるというのは嬉しい*2。機会があればもうちょっと突っ込んだ話とかをしたいね。
