3

私が考えることができる 2 つの明白な場所は、私が取り組んでいるコードのすぐ隣にあるある種の「テスト」フォルダーです。次のようなものです：

\project-code
    \my-feature
        \production-code
        \testing
            ***my tests***
    \co-workers-feature
        \production-code
        \testing

または、テスト コードを完全に別の階層に分割することもできます。次のようなものです：

\project-code
    \my-feature
    \co-workers-feature
\testing-project-code
    \my-feature
        ***my tests***
    \co-workers-feature

多くのフレームワークが 2 番目のアプローチを使用しているのを見てきましたが、最近では主に便宜上、テスト コードを製品コード内に配置しています。あるアプローチが他のアプローチよりもはるかに優れているか、それともベストプラクティスはありますか?

4

5 に答える 5

2

あなたにとって最も便利な場所に置いてください。必要に応じて、最終製品からそれらを削除するようにビルド システムを設定できます。テストは「ベスト プラクティス」です。有効性を低下させずにテストを容易にするものは、単にベスト プラクティスを改善するだけです。

于 2009-12-10T17:51:49.860 に答える
1

私はユニットテストを近くに保つことを好みます。オプション1がうまく機能するのを見てきました。小さなプロジェクトの場合、どちらのアプローチも問題なく機能しますが、プロジェクトがどんどん大きくなるにつれて、ツリーの非常に異なる部分にテストが存在する場合、テストを見つけて維持することが難しくなります。それらが近い場合、製品コードを変更するときにそれらを変更するのは自然です。彼らが遠くにいる場合、それはより多くの精神的な努力を要し、より無視されます。これは、それらが同期していない可能性が高いことを意味します。

これを行うには、テストディレクトリの条件付きコンパイルを可能にするmakeシステムが必要であることに注意してください。毎回ビルドする必要はありません。それが得られない場合は、別のツリーが必要になる場合があります。

于 2009-12-12T09:23:49.193 に答える
1

私は 2 番目のオプションを使用します。つまり、必要に応じてテストなしでコードを出荷できます。また、クラスまたはパッケージを見ると、単体テストがどこにあるかがわかります。

関連する質問は次のとおりです。

単体テストを同じプロジェクトまたは別のプロジェクトに配置しますか?

于 2009-12-10T17:55:42.657 に答える
0

あなたが管理しているウェブサイトであれば、すべてを同じフォルダに入れても問題ありません。リリースするクラシック ソフトウェアの場合は、ケース 2 のように分離することをお勧めします。これにより、リリース時に誤って肥大化することがなくなります。

于 2009-12-10T17:46:05.143 に答える
0

私にとっては、特に SCM の観点からは、最初のオプションの方が理にかなっています。プロダクション コードとテスト コードは適切に同期されており (そうあるべきです)、プロジェクトにタグを付けるかブランチする場合は、プロダクション コードとテスト コードの両方にタグを付けるかブランチします。同時にコードをテストします（必要に応じて）。

于 2009-12-10T17:55:23.083 に答える