アカウント名:
パスワード:
単体テストがあれば、いつでもリファクタリングできます。予算ウンヌンの話が出ていますが、要求される納期に間に合わなければいくらテストがあってもリファクタリングはできません。ただし、リファクタリングすることによって要求される仕様の実現がスピードアップする場合はこの限りではありません。
プロダクトであれば、エンハンスのときに開発メンバが「自分たちのために」頑張って残業でもなんでもしてリファクタリングしてしまえばよいのです。ただし、この場合ひとりよがりなリファクタリングはいけません。あくまで、「コードの共同所有」ができることが前提です。
おそらく、リファクタリングをしたいならば、単体テストを自動化しておくしかありません。そうしておけば、基本的な機能に関して単体テストで担保されますから、大胆な変更も気軽にできるに違いない、と思われます。
…という意見を他で聞いたことがないのは、自分と自分の周りの スキルが低すぎなのでしょうか…。
…と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。 ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。 しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル(((( SE何年やってんだ。逝ってきます…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
JUnit, etc. (スコア:4, 参考になる)
ただし、「動いているものを触るな」文化においては、単体テストを自動化できているということそのものが幻想に近い、という現実があるように思えます。
とくに、既存のアプリケーションの改修において単体テストを自動化して導入しろ!といわれても、もともと単体テスト向きに実装されていなかったりして、リファクタリングもできずに泣きそうになることうけあいです。
# 単体テスト環境を整えろ!という状況におちいっているのでID
バージョン管理もね (スコア:2, すばらしい洞察)
テストなきリファクタリングはダメです (スコア:2, 参考になる)
単体テストがあれば、いつでもリファクタリングできます。予算ウンヌンの話が出ていますが、要求される納期に間に合わなければいくらテストがあってもリファクタリングはできません。ただし、リファクタリングすることによって要求される仕様の実現がスピードアップする場合はこの限りではありません。
プロダクトであれば、エンハンスのときに開発メンバが「自分たちのために」頑張って残業でもなんでもしてリファクタリングしてしまえばよいのです。ただし、この場合ひとりよがりなリファクタリングはいけません。あくまで、「コードの共同所有」ができることが前提です。
Re:JUnit, etc. (スコア:1)
単体テストの自動化は、新規開発時にやっておいたことがあります。
1年くらいの間は楽が出来ました。
まぁ、引継ぎを行って3ヵ月後には引き継いだ方々の無茶な改造で
まったく無意味になってしまいましたが。
かといって、途中から自動化ってのは、そのコストを負担するのがいやで
後々の世代までずるずる引き延ばされてしまうこと往々です。
まぁあとの世代で実施されたのを見たことはありませんし、
僕もやったことはありませんが。
単体テストは現実的? (スコア:1)
「テストはリファクタリングに踏み出す勇気を与えるためのもの」
でテストコードで保証は取れないという話を見た記憶があります。
どこまで現実的なのかな~。。
それともテストコードがきっちり書けるクラス設計を、という事なのでしょうか。ん~。
Re:単体テストは現実的? (スコア:2, 参考になる)
>でテストコードで保証は取れないという話を見た記憶があります。
XPでいう「勇気」は、ギャンブルに突入するための勇気…蛮勇…のことを指すのではなく、
ギャンブルでなくきちんとやれる目処をつけることを指す、のだったと思います。
#実際できるかどうかはさておき、主張としてはそういうこと、だったと…
ところで、「テスト可能な」アプリケーションの設計 [ibm.com]なんてなwebページはいかがですか?
>それともテストコードがきっちり書けるクラス設計を、という事なのでしょうか。ん~。
「単体」をきちんと定義できているかどうか?っていう問題は、有ると思います。
どっからどこまでが単体なんだかワケワカなぐちゃぐちゃ設計だと、
XPだろうがなんだろうが、何持って来ようが救えないんだと思います。
上記ページによると、どうやら所謂狭義の「設計」だけをきちんとしてればテストができる、というものではないようです。
色々心がけるべき事柄が有るようです。
Re:JUnit, etc. (スコア:1)
そもそも、テストコードに全く変更を行わずにリファクタリングが できるほどスマートなクラス設計をしているのであれば、実装を書き直して品質を高める余地は少ないのでは? そしてリファクタリングを行うたびに単体テストコードを書き直すのは結構厄介でやる気が失せる作業です。
…という意見を他で聞いたことがないのは、自分と自分の周りの スキルが低すぎなのでしょうか…。
Re:JUnit, etc. (スコア:3, 参考になる)
自分も最初は同じ意見でしたが、
クラス設計以前のお客との意識あわせと要件の
煮詰めが一番重要で、その要求を満たすこと
"お客に上げてもらい"それをテストコードで記述するのです。
クラスの設計の前に、お客自身に自分の言っている
事の矛盾を自覚させ、自分自身の価値を再認識
させることが重要なステップです。
と、最近気付いてようやっと回り始めました。
Re:JUnit, etc. (スコア:0)
原則ブラックボックステストを行うのが試験工程の基本だったっと思います
ので、いちいちつくりなおすという事は、試験するという事はどういう
事かが理解でき
Re:JUnit, etc. (スコア:1)
JUnitのようなツールを使って単体テストを行う場合の「ブラックボックス」とはメソッドの中身がブラックボックス、になりませんか?
…と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。
ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。
しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル((((
SE何年やってんだ。逝ってきます…。
Re:JUnit, etc.ケント・ベックのTDD本 (スコア:0)
http://www.amazon.co.jp/exec/obidos/ASIN/4894717115/249-6954101-0818734
つーか、この本、目からウロコでした。