アカウント名:
パスワード:
おそらく、リファクタリングをしたいならば、単体テストを自動化しておくしかありません。そうしておけば、基本的な機能に関して単体テストで担保されますから、大胆な変更も気軽にできるに違いない、と思われます。
よく上のような言葉を単体テストツールの利点として目にするのですが、本当にそうなのでしょうか?? そもそも、テストコードに全く変更を行わず
…と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。 ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。 しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル(((( SE何年やってんだ。逝ってきます…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
JUnit, etc. (スコア:4, 参考になる)
ただし、「動いているものを触るな」文化においては、単体テストを自動化できているということそのものが幻想に近い、という
Re:JUnit, etc. (スコア:1)
よく上のような言葉を単体テストツールの利点として目にするのですが、本当にそうなのでしょうか??
そもそも、テストコードに全く変更を行わず
Re:JUnit, etc. (スコア:0)
原則ブラックボックステストを行うのが試験工程の基本だったっと思います
ので、いちいちつくりなおすという事は、試験するという事はどういう
事かが理解できていないのではないでしょうか?
「プログラムが考えた通りに動いている」というテストばかりして
いませんか? あなたの考えている動作が目的に合致しているという
保証がどこにあるのでしょう?
Re:JUnit, etc. (スコア:1)
JUnitのようなツールを使って単体テストを行う場合の「ブラックボックス」とはメソッドの中身がブラックボックス、になりませんか?
…と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。
ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。
しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル((((
SE何年やってんだ。逝ってきます…。