アカウント名:
パスワード:
おそらく、リファクタリングをしたいならば、単体テストを自動化しておくしかありません。そうしておけば、基本的な機能に関して単体テストで担保されますから、大胆な変更も気軽にできるに違いない、と思われます。
…という意見を他で聞いたことがないのは、自分と自分の周りの スキルが低すぎなのでしょうか…。
…と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。 ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。 しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル(((( SE何年やってんだ。逝ってきます…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
JUnit, etc. (スコア:4, 参考になる)
ただし、「動いているものを触るな」文化においては、単体テストを自動化できているということそのものが幻想に近い、という
Re:JUnit, etc. (スコア:1)
そもそも、テストコードに全く変更を行わずにリファクタリングが できるほどスマートなクラス設計をしているのであれば、実装を書き直して品質を高める余地は少ないのでは? そしてリファクタリングを行うたびに単体テストコードを書き直すのは結構厄介でやる気が失せる作業です。
…という意見を他で聞いたことがないのは、自分と自分の周りの スキルが低すぎなのでしょうか…。
Re:JUnit, etc. (スコア:3, 参考になる)
自分も最初は同じ意見でしたが、
クラス設計以前のお客との意識あわせと要件の
煮詰めが一番重要で、その要求を満たすこと
"お客に上げてもらい"それをテストコードで記述するのです。
クラスの設計の前に、お客自身に自分の言っている
事の矛盾を自覚させ、自分自身の価値を再認識
させることが重要なステップです。
と、最近気付いてようやっと回り始めました。
Re:JUnit, etc. (スコア:0)
原則ブラックボックステストを行うのが試験工程の基本だったっと思います
ので、いちいちつくりなおすという事は、試験するという事はどういう
事かが理解でき
Re:JUnit, etc. (スコア:1)
JUnitのようなツールを使って単体テストを行う場合の「ブラックボックス」とはメソッドの中身がブラックボックス、になりませんか?
…と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。
ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。
しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル((((
SE何年やってんだ。逝ってきます…。