1

たとえばConnectionDummy、 Maven projectにファイルがありますCommon。Email-Lib、Scannerおよびのテストでのみ使用されますCommon。NoteCommon自体にも単体テストが含まれていますが、これらのファイルは単体テストのヘルパーにすぎません。それは行くべきCommonですtestかmain？

Maven設定ですが、これはおそらく多くのテクノロジーに共通していると思います。

4

1 に答える 1

2

それは、本番システムでテスト (ユーティリティ) コードを使用することについて、あなたがどれだけ強く感じているかによって少し異なります。何もせずに座っているだけのコードは、本番環境に悪影響を及ぼしますか? テスト ユーティリティに、たとえば Spring が実行時に取得する気の利いた注釈があると想像してみてください。

私は気にしない人に出くわしました。個人的には強く感じており、実稼働環境でコードをテストしたくありません。あなたもそう考えているなら、Maven を使用する方法は 2 つあります。

  1. テスト ユーティリティ コードは、Common のtestフォルダーに配置されます。共通プロジェクトのテスト JAR ( ) を構築することになり、誰かがテスト JAR に依存しているときに、テスト ユーティリティ コードが必要とする共通プロジェクトの依存関係が存在しないというtest-jar推移的な依存関係の問題に遭遇する可能性があります。 <scope>test</scope>. これは潜在的な依存関係の悪夢であり、「インクルード プロジェクト」によってすでに適切に定義されていた多数の依存関係を再定義する「インクルード プロジェクト」を見てきましたが、スコープ テストで推移的であるために Maven によって検出されませんでした。 .

  2. テスト ユーティリティ コードは、別のテスト プロジェクトに入れます。たとえば、CommonTest は、パッケージ化jarではなくを生成します。test-jarそうすれば、テスト ユーティリティは、依存プロジェクトだけでなく、元の Common プロジェクト自体に対しても同じように「ユーティリティ」になります。そうすることで、testフォルダーは本当にプロジェクトの内部の問題になります。たぶんそれが Maven の連中が意図したことなのかもしれtest-jarません。:)

于 2013-04-12T08:34:53.043 に答える