どこまで設計をするかってのも、規模によって変わってくるよね。
っていうか、困るのが、要件仕様がハッキリしない場合。How（どうやって実装するか）は事前に決まって無くても問題ないと思います。だけど、What（何を書くのか）を事前に決めないでプロジェクトが始まることが多い。あと、マネージャもリーダーも How と What を区別できてなかったり。
XP で言うところの、Planning Game とか User Story から生まれる Task Card が無いと、話にならない。XP やるとしても、コードだけで考えると煮詰まるのでスケッチモードの UML [amazon.co.jp] はお勧めです。
テスト専任 (スコア:2, 興味深い)
あと、設計がキッチリ決まってない場合は、開発者以外がテストコードを書くのは難しいんじゃないかな。コードに手を入れる権限がある程度必要になってくるから。ユニットテストの話をすると、全てのコードがテストできるってわけじゃないと思うんですよ。メソッドに何十行もずらーーっと書いてあるよ
Re:テスト専任 (スコア:1)
> 開発者本人がテスト書いた方がよっぽど早いわけ。
そりゃそうだ。でも、コードの振る舞いを理解して、それに従って試験を記述する場合、何を試験しているのかよくわからないですね。だって、コードの振る舞いに合う、つまり、必
Re:テスト専任 (スコア:2, 参考になる)
どこまで設計をするかってのも、規模によって変わってくるよね。
っていうか、困るのが、要件仕様がハッキリしない場合。How（どうやって実装するか）は事前に決まって無くても問題ないと思います。だけど、What（何を書くのか）を事前に決めないでプロジェクトが始まることが多い。あと、マネージャもリーダーも How と What を区別できてなかったり。
XP で言うところの、Planning Game とか User Story から生まれる Task Card が無いと、話にならない。XP やるとしても、コードだけで考えると煮詰まるのでスケッチモードの UML [amazon.co.jp] はお勧めです。
> 必ず合格する試験を記述するんでしょ？
これは、挙動がある程度複雑だと、いつでも合格というわけにはいかないと思います。凡ミスを拾うことも多い。
だけど、自動化されたテストの一番の強みは、将来コードに色々拡張が入ったり、ネットワークの設定を変えたりみたいな外部環境の変化があった時に実装したコードがちゃんと動いてるかを手軽にチェックできることにあると思います。極端な話、値をチェックしてなくても、ある部分を呼び出してるだけでも、テストとしての役割はあると思います。
>> データの状態によって出てくるバグってのも少なくなる。
って書いたのはその事で、例えば、名前が「j」で始まる記録をデータベースから削除した時のみに行われる一連の振る舞いがあったとして、運用中にそういう記録が稀にしかない場合とか。運用に入って、しばらくしてからキャスティングミスで突発バグ。