ファイルシステム仕様とそのテストの拡張

ファイルシステムの仕様は不完全です。すべての操作、あるいはFileSystem API のインターフェースやクラスを網羅していません。網羅されている部分にも、コーナーケース、失敗モード、その他の予期しない結果など、いくつかの小さな問題がある可能性があります。また、標準的なFileSystemが仕様から大きく逸脱しており、それを文書化してテストで対応する必要があると感じる場合もあります。

最後に、FileSystemのクラスとメソッドは永遠に固定されているわけではありません。既存のクラスに新しい操作を追加したり、まったく新しいクラスやインターフェースを追加したりすることもあります。

したがって、この仕様をHadoopコードの他の部分と同様に、完全な静的ドキュメントとは見なさないでください。

  1. 参照実装（HDFS）と、ファイルシステムを検証するために使用されるテストを補完するライブドキュメントとして考えてください。
  2. 拡張または修正することを恐れないでください。
  3. FileSystem API の機能強化を提案する場合は、それに合わせて仕様を拡張する必要があります。

この仕様の更新方法

  1. hadoop-commonコードベースにあるものの、HDFSチームはFileSystemとFileContext APIの所有権を持っています。hdfs-devメーリングリストで彼らと協力してください。

  2. APIや仕様の変更に対応するために、HADOOPプロジェクト、コンポーネントfsでJIRA課題を作成してください。

  3. コードの変更には、もちろんテストが必要です。理想的には、仕様自体の変更には新しいテストが伴います。

  4. 変更が既にAbstract*ContractTestを持つ操作を含む場合は、そのクラスに新しいテストメソッドを追加し、それをサブクラス化するファイルシステム固有のテストで機能することを確認します。これには、オブジェクトストアだけでなく、ローカルファイルシステムとHDFSファイルシステムも含まれます。

  5. 変更で新しい操作を追加する場合は、既存のものと同じ契約駆動型アーキテクチャを持つ新しい抽象テストクラスと、その操作をサポートするすべてのファイルシステムのインプリメンテーションサブクラスを追加します。

  6. 無効な前提条件が予期されるエラーにつながることを検証するテストメソッドを追加します。

  7. 有効な前提条件がファイルシステムの予期される最終状態につながることを検証するテストメソッドを追加します。テストごとに可能な限り少ないテストを行うことで、問題の追跡が容易になります。

  8. 可能な場合は、同時実行の期待を示すテストを追加します。

新しく追加されたテストでFileSystemが失敗した場合は、次の可能性があります。

  • 仕様が間違っている。
  • テストが間違っている。
  • テストが間違った例外を探している（つまり、厳しすぎる）。
  • 仕様とテストは正しい-ファイルシステムが期待と一致していない。

HDFSは、その動作において正しいものとして扱われなければなりません。テストと仕様がこの動作と一致しない場合は、仕様を更新する必要があります。それでも、FSを変更できる場合があります。

  1. より有益なサブクラス（EOFExceptionなど）を発生させることができる場合に、発生する例外が一般的なIOExceptionです。
  2. 無効な引数のセットを渡された場合、FileSystemが正しく失敗しません。これは修正できる可能性がありますが、慎重に行う必要があります。

不一致がLocalFileSystemにある場合は、これはJava IO APIを介してアクセスされるネイティブファイルシステムであるため、おそらく修正できません。

他のFileSystemの場合、HDFSやLocalFileSystemの動作をより正確に反映するように動作を更新できます。ほとんどの操作ではこれは簡単ですが、rename()のセマンティクスは複雑であるため、HDFSが正しい参照であるとは限りません。

テストが失敗し、修正不可能なFileSystem固有の問題であると思われる場合は、結果の異なる解釈を許可する新しい契約オプションをContractOptionsインターフェースに追加し、オプションの有無に応じて反応するようにテストを変更し、標準FileSystemのXML契約ファイルを更新して、機能/失敗モードが存在するかどうかを示す必要があります。