JUnit内のウィザードを使用してTestCaseまたはTestSuiteを作成できることは知っていますが、メソッドシグネチャの変更や新しく追加されたメソッドなど、テスト対象のクラスが変更された後、コードを同期するにはどうすればよいですか。TestCasesで、変更されたメソッド/パラメーター/メソッドシグネチャをTestCases内で同期(削除または追加)できるようにしたいと思います。
グーグルで検索してみましたが、役に立たなかったのですが、そのための日食プラグインがあるのでしょうか?
JUnit内のウィザードを使用してTestCaseまたはTestSuiteを作成できることは知っていますが、メソッドシグネチャの変更や新しく追加されたメソッドなど、テスト対象のクラスが変更された後、コードを同期するにはどうすればよいですか。TestCasesで、変更されたメソッド/パラメーター/メソッドシグネチャをTestCases内で同期(削除または追加)できるようにしたいと思います。
グーグルで検索してみましたが、役に立たなかったのですが、そのための日食プラグインがあるのでしょうか?
前に述べたように、名前の変更や移動などのリファクタリングは、たとえば手動で名前を変更するのではなく、Eclipse ツールを使用してリファクタリングする限り、テスト ケースに自動的に反映されます。
新しいメソッドに関しては、テストを自動的に生成することは不可能です。もちろん、生成を制御し、テストケースを生成できる自動生成コードにはいくつかの例外がありますが、「通常の」手動コードでは、スタブ (空のメソッド) を提供することが最善であり、その用途は何ですか?その中で?
より良いアプローチは、 Cobertura や Emma などのツールを使用してコード カバレッジを追跡することです。これらのツールには、ソース コード内でどのコードがテストでカバーされ、どのコードがカバーされていないかを確認できる優れたEclipse プラグインがあります。これは、さらにテストが必要な場所のレポートです。
製品コードの構造と 1 対 1 の関係にあるテストは、テストのにおいです。本番コードに基づいてテストを生成する (メソッドごとに ~ 1 つのテスト) よりも、テストをシステムの動作の仕様 (動作ごとに ~ 1 つのテスト) として記述する方がはるかに優れています。
http://blog.daveastels.com/files/BDD_Intro.pdfから引用
テストを書くことではなく、動作を指定することがすべてであることに気付くと、視点が変わります。プロダクション クラスごとに Test クラスを用意するという考えは、途方もなく制限的です。そして、それぞれのメソッドを独自のテスト メソッドで (1 対 1 の関係で) テストするという考えはばかげています。
自動リファクタリングを使用してメソッド シグネチャを変更すると、テスト ケース (およびメソッドを呼び出す他のすべてのコード) が自動的に更新されます。
新しく追加されたメソッドについて、テスト クラスを自動的に更新する方法がわかりません。