0

私は、nunit (および一般的な Java 開発) を使用した単体テストは初めてです。クラスのプライベート メソッドの単体テストを作成する場合、テスト ファイルはテスト対象のクラスと同じパッケージ内にある必要があるように見えます。単体テストの API のエクスポートを回避する一般的な方法は何ですか? クラス/テスト メソッドをパッケージ保護することはできますか? それとも、開発者は通常、単体テスト ファイルを除外したリリース用の別のビルドを持っていますか?

4

5 に答える 5

1

IntelliJ または Ant に、デプロイメントで JUnit テストをパッケージ化しないように指示できます。ソースコードとは別のディレクトリにテストがあります。これがそれを可能にしています。

ソース クラスとテスト クラスを一緒にしないでください。デプロイに使用するツール/スクリプトが簡単になるように、それらを分けておいてください。

于 2008-12-31T16:43:05.280 に答える
0

テスト ファイルは、テスト対象のクラスと同じパッケージにある必要はありません。実際、パッケージ レベルの実装の詳細に関係なくパブリック API をテストできるように、テスト ファイルを完全に別のパッケージに入れることをお勧めします。

または、ビルド スクリプト (Nant など) を設定して、リリース実行可能ファイルをビルドするときに "Test" を含むファイルを無視することもできます。

于 2008-12-31T16:44:11.020 に答える
0

テスト コードを CUT (Class Under Test) のパッケージから移動するのは間違いだと思います。ある時点で、保護されたメソッドまたはクラスをテストしたい場合がありますが、テスト コードを別のパッケージに入れると、それが困難または不可能になります。

より良い解決策は、運用コードのパッケージ構造を単純に反映するテスト コード用の別のディレクトリを作成することです。これが私がすることです：

src/main/java/com/example/Foo.java
src/test/java/com/example/FooTest.java

src/test/**そうすれば、ビルド スクリプトは、パッケージ化と展開の段階になると、非常に簡単に無視できます。

于 2009-01-02T02:00:21.083 に答える
0

テスト ソース コードをアプリケーション ソース コードから除外します。一般に、公開された機能のみをテストします。プライベートな動作を本当にテストする必要がある場合は、実際のオブジェクトを拡張し、パブリックなアクセスをプライベートな動作に許可するテスト オブジェクトを作成します。

于 2008-12-31T21:31:59.893 に答える
0

個人的に私のアプローチは公開された機能をテストすることだけなので、うまくカプセル化された部分だけをテストすることになります。

これにより、通常、テストが容易な、明確に定義された機能を持つ小さなクラスがデザインに含まれるようになります。

一般に、単体テストでは、テスト対象の内部に関心を持つべきではないため、これが最善のアプローチ方法であることがわかりました。

また、テスト コードと製品コードを分離するのが最善であることに同意します。

于 2008-12-31T17:00:03.250 に答える