私は 1 年前の Java/J2EE プロジェクトで 2 か月を過ごしましたが、既存の JUnit テストが私のせいで失敗するたびに、それは JUnit テストが時代遅れであるか間違っていたことが原因でした...メソッドの名前が変更されたために失敗したか、またはメソッドが間違って実行されたために失敗したかどうかをテストします"...
では、どのようなメソッドに対して、どの程度のテストケースを実装すればよいのでしょうか? プロジェクトのどの時点で、その理由は? 要約すると、テストケースについて教えてくれる良い習慣はありますか?
ありがとう！
主要な本を埋めることができる 10 の質問をしています。私はいくつか
答えようとしています:
単体テストは主にモジュール テスト用ですが、統合テストにも使用できますが、統合の範囲は二次的なものです。when
単体テストの発明者は、「テスト ファースト」(事前にテスト ケースを作成する) という用語を導入しました。これは、彼が知っている SW 開発者のほとんどが怠惰で規律に欠けていたためです。彼が後でテストすることを勧めていたら、多くのテストは決して書かれなかったでしょう。
私のアプローチは、30% を完了してからテストすることです。そうしないと、テストに使用できる構造がありません。私はそれを「テスト初期アプローチ」と呼んでいます
。Junit
テストには便利ですが、ユーザー インターフェイス テストにはあまり役に立ちません。
単体テストは、高度な統合性を持つモジュール (集中管理メソッド) の場合、記述するのが少し難しくなります
。それ以外の場合は、非常に便利です。特に、それらはアルゴリズムの数式、あらゆる種類の計算に必須です。
主な利点の 1 つは、単体テストを作成することで、実際のコードでの時間のかかるデバッグを回避できることです。単体テストを書いて失った時間は、そのデバッグを回避することで得られます。
ソース コード ステートメントの 80% の単体テスト カバレッジまで、単体テストは追加のプロジェクト コストを作成しません。
私の経験では、getter と setter でさえ単体テストする必要があることがわかりました。これは、クラスごとに 2 分で実行できるためです (testGetterSetter() を使用)。昨年、setter と getter に 2 つの重大なバグがありました。
メソッドの名前が変更されたためにのみ失敗する場合
eclipse refactor->rename を使用すると、同じプロジェクト内にある限り、Unit ケースがリファクタリングに含まれます。これは推奨されます。
もちろん、ソースコードの変更により、ユニットケース、src、およびユニットテストフォームを一緒にユニットに適合させる必要が生じる可能性があります。
最後に、単体テストの主な利点の 1 つは、いくつかの変更を含む新しいリリースを作成する場合でも、すべての単体テストが実行されていることを把握できることです。これは、退職した同僚を引き継ぐ場合に特に重要です。