阿部です、こんにちは。
>> 個人的には、後からテストコードを書いてもいいと思ってます。ただし、
>>リファクタリングの必要性があるなら、という条件付で。リファクタリングしたい
>>ならまずテストを用意しろ、という点は、精神安定のためにも譲れないですね。
>>でないと怖くてできません。当然、品質保証のためにも。
>> でも、完成したコードをリファクタリングする利点があるのか？という点を
>>考慮する必要はあると思います。
>
>テストコードですが、私は、始めに書いてしまうのが理想的と考えています。
>テストコードを作成する意味は、品質評価（テスト）のためだけではなく、
>実際のコーディングの道しるべとして使用すると言う思いがあるからですが。
ええ、もちろんそうです。
私が上記の発言をしたのは、島田さんのように「既存のコードをいじりたいが
テストコードがない」という場合に、じゃあまずテストコードを書いてから
リファクタリングしましょうね、と言ったんです。
>テストコードを正常に動作させる事を意識してコーディングを行う事が
>本来の目的であり、バグ軽減を期待できると思うのですが。
ということで、普段は私も先に（ほとんど「同時」というパターンが多いんですが）
書いてます。ただし、JBuilderを使っているのでコード補完の為にも
１．中身が空っぽか、ダミーを返すコードを書く
２．それをもとにテストを書く
３．ダミーを実装する
というパターンが多いですね。
当社では導入したばかりで、ペアプロはほとんどOJT目的がメイン。タスクカードは
書き忘れてばかり（笑）、共同所有はあまり芳しくない、といった状況です。これから
リファクタリングを始める（stableをリリースしてcurrentになってから、リファクタリング
します）ので、それがどういう結果を生み出すか楽しみですね。
リファクタリングには当然コストがかかりますから、慣れているならともかくいきなり
大規模なリファクタリングをすると、保守性の向上とコスト増のバランスが崩れます。
その見極めをするための、指標なり資料なりってあるんでしょうか？
>ただ、組み込み系などでは、ファーストテストは、ブラックボックステストと
>同等と考えられているようで（現在の環境下では全てのパスが通ったかのチェック
>を行わなければいけない）受け入れられがたい用です。
>結果よければ全てよしとではだめだと・・・・。
ソースコードレビューが必然、というパターンではテストもそうですが
リファクタリングも安易に行えないですね。（レビューのやり直しになるし）
-------------------------------------------------------------
Takashi Abe <abetaka@....jp>
HP: http://homepage1.nifty.com/taka-page/
合気道 薫友会 : http://homepage2.nifty.com/kun-yu/index.html
-------------------------------------------------------------