ユニットまたは統合テストリソースファイルのディレクトリレイアウト

Question

ユニットまたは統合テストリソースディレクトリの一般的なアプローチは、のネストされたレイアウトですか？例えば、コードならば、テストは、リソースは、このテストのためのリソースファイルを格納するapproachs

main/ 
    java/ 
    com/ 
     example/ 
     Class.java 
test/ 
    java/ 
    com/ 
     example/ 
     ClassTest.java 
    resources/ 

Javaプロジェクトのように教えてください。strucuredされていますか

非常に単純なケースでは、ファイルをたとえばtest/resources/a.xmlがありますが、各テストにソースと期待出力ファイルがある複数のテストがある場合、これは機能しません。ソリューションの例としては、

test/ 
    resources/ 
    com/ 
     example/ 
     ClassTest/ 
      src/ 
      a.xml 
      b.xml 
      exp/ 
      a.xml 
      b.xml 

可能性があり複数テストのため複数リソースファイルを構成するすべての一般的なアプローチがあります。

Answer 1

正直言って、開発者がいるほど多くの方法があります。しかし現実的には、今から6〜2年後にはあなた自身や他の誰かを次の開発者と考えてください。彼らはファイルとコードの関係を容易に理解できるでしょうか？彼らは簡単に新しいテストを追加したり、古いものを維持することができますか？どんな慣習が役立つでしょうか？

あなたが選んだレイアウトは、次の開発者があなたであっても、あなたが今他のことをするために知っているものをロードしている可能性が高いため、この考慮事項を反映する必要があります。だから帰ってきたら、あなたは行くつもりはない - 「WTFは私が思ったの？」 :-)あなたはもう一度作業を開始したいだけです。