0

ディレクトリをナビゲートし、ファイルを操作するためのメソッドを提供するモジュールに取り組んでいます。基本的にはDirFileクラスの組み合わせで、私が取り組んでいるプロジェクトのニーズに固有のオプションがあります。

今、私はこれらのメソッドのいくつかのテストを書き始めましたが、物事は混乱しています。

私が持っている方法の 1 つは、treeファイルとフォルダーのハッシュを返す関数で、tree(only: 'folders', limit: 3). 3 レベルしか下がらないことをテストするには、ダミー ファイルを含む 4 つ以上のサブフォルダーが必要です。

問題

現在、サブフォルダーが既に存在するため、プロジェクト外のフォルダーでテストしていますが、特にシステムファイルでのテストの妥当性を考慮して、rm -rf(および携帯性)。

私はすべての「実験」を行う「実験用ラット」タイプのフォルダーを作成する必要があると考え始めていますが、それを作成する方法がわかりません。

  • ファイルを作成する関数を作成しますか?
  • ファイルやフォルダを別の場所からプルする必要がありますか?
  • ファイル構造に何らかの「lorem ipsum」ジェネレーターを使用する必要がありますか?
  • これらのファイルとフォルダーはすべて手動で作成しますか?
  • ファイルやフォルダーを実際に作成/削除するのではなく、すべてをモックしてスタブするだけですか?(私はこれが起こっているとは思いません)

そう...

過剰な量のファイルやフォルダー操作をテストするには、通常どのようにアプローチしますか?

4

1 に答える 1

1

モック/スタブを使用したくないと思います。OS のファイル システムは十分にテストされ、高速である必要があるため、モック/スタブの利点は最小限に抑えられます。モック/スタブ システムを作成すると、あまりメリットがなく複雑さが増します。

ここに私の答えがあります:

ファイルを作成する関数を作成しますか?
はい。これらの関数のテストを作成して、それらが正しいことを確認できます。Dirandを呼び出す代わりにFile、コードを単純で読みやすいものにするヘルパー関数を記述します。ソース/テストコード間でヘルパー関数を共有できるかもしれません...

ファイルやフォルダを別の場所からプルする必要がありますか?
これは何のためにあるのかわからない...

ファイル構造に何らかの「lorem ipsum」ジェネレーターを使用する必要がありますか?
はい、ファイル構造を生成する関数を作成するという意味であれば。

これらのファイルとフォルダーはすべて手動で作成しますか?
いいえ。

ファイルやフォルダーを実際に作成/削除するのではなく、すべてをモックしてスタブするだけですか? (私はこれが起こっているとは思いません)
いいえ。テストに 100% 依存することはありません。これがないと、ソース コードとテスト コードの両方が期待どおりに動作しないというバグが発生する可能性があるため、これは実際には良い方法です

于 2012-10-28T02:48:49.580 に答える