- plum_shiga
- 918
- 0
- 0
- 0
@horine_emi 基本は作るけど、自動テストする範囲は作らないな。手動でテストする範囲だけなので気持ち悪いほど長いドキュメントはないw
2014-06-17 21:11:03@misty_wind なるほど。ウチ自動でやってないし、単テは技術者で勝手にチェックしてねっていうスタンスなので、気になってた。ありがとう!
2014-06-17 21:13:03@plum_shiga @misty_wind ウチが適当すぎるだけじゃないかなー。とりあえずヤバそうなところは結合でやってる。結合なのか単テなのかよく分からないテストになってて、やたらめったら件数多いわ…
2014-06-17 21:15:35@plum_shiga @horine_emi 理想は単テでつぶしておいて後ろの工程のケース減らす、そのために自動化だと思うんやけど、導入コストがかかるんだよなあれ…
2014-06-17 21:18:25@plum_shiga @misty_wind キッチリやってるって意味ならいいんじゃないかな?私は単テ含めてて件数増えてるので。
2014-06-17 21:18:33@misty_wind @plum_shiga それです。やりたいのはやりたいけど、初期コストが見積もれない。しかもそのコストどっからもってくるの?っていう、ね
2014-06-17 21:19:35@horine_emi @plum_shiga テスト工数削減だけ見ると導入がってなるけど、リグレッションテストしやすくなる点では品質にも効果あると思うんやけどなあ
2014-06-17 21:21:40@misty_wind @plum_shiga それでいくとウチのプロジェクトだとそこのメリットが他より少ないんだよね。ちゃんと製品化してない実験段階のやつなので、すぐに仕様変わって作り直しっていう。効果ないわけじゃないけど、導入コストとどっちがどうかなーって
2014-06-17 21:24:15@misty_wind @horine_emi @plum_shiga 横入り失礼します。ユニットテストの自動化は、継続的インテグレーションにおける回帰テストの工数を減らす目的で導入されます。つまり、短期間で頻繁な変更・リリースが発生する場合に効果を発揮します。(続く
2014-06-17 21:25:24@misty_wind @horine_emi @plum_shiga 続き)なので、SIでよくある、「一度きりの納品」とか「納品して数ヶ月は変更しない」という場合だと導入コストの方が大きくなってしまって、意味がない場合の方が多いです。
2014-06-17 21:26:05@horine_emi @plum_shiga あーーなるほど、うちみたいに保守開発やと過去のケースやる必要も多々発生するけど、そういうのやと微妙かもしれないな
2014-06-17 21:26:10@daiksy @horine_emi @plum_shiga うちのPJが大型保守開発だからかもしれないですねー過去のテストケースとかマスタで管理してるし
2014-06-17 21:27:24@horine_emi @misty_wind @plum_shiga ですね。数カ月後に本当に触る、そしてそのときにユニットテストもきちんとメンテナンスする、なら絶大な効果を発揮します。
2014-06-17 21:31:52@horine_emi @misty_wind @plum_shiga 「書いたテストケースがいらなくなる」問題は、仕様が変わっているのであれば当然それに対応するテストケースもメンテナンスする必要があるので、そこのコストを払えるか、という問題になりますね。
2014-06-17 21:33:21@misty_wind @horine_emi @plum_shiga 経験的にはメンテナンスコストを払っても得られる効果の方が高いという気はしていますね。いずれにしろシステムを改変するならなんらかのテストコストは必要なわけですからね。
2014-06-17 21:34:19@daiksy @misty_wind @plum_shiga どちらにせよメンテナンスがちゃんと追い付いてれば効果ある、で認識しました。でもやっぱりやってみないとイメージつかない気がしてるので、ちょっと調べてみます…
2014-06-17 21:36:18@horine_emi @misty_wind @plum_shiga がんばってください! 『JUnit実践入門』とかオススメです!
2014-06-17 21:37:18