3

jekyll投稿ファイルを生成できるRubygemを作成しています。私がこのプロジェクトを開発している理由の1つは、TDDを学ぶことです。_postsこのgemはコマンドラインで厳密に機能し、ディレクトリが見つかることを確認するために一連のチェックを行う必要があります。これは2つのことに依存します：

  1. locationオプションが渡され たかどうか
    • その場所のオプションは有効ですか？
  2. ロケーションオプションが渡されませんでした
    • 投稿は現在のディレクトリにありますか？
    • 投稿は現在の作業ディレクトリにありますか？

その時点で、私はアプリケーションのその部分をテストするのに本当に苦労しています。だから私は2つの質問があります：

  • 上記のようなアプリケーションの小さな部分のテストをスキップすることは許容されますか/大丈夫ですか？
  • そうでない場合は、minitestを使用してrubyでファイル操作をどのようにテストしますか？
4

2 に答える 2

2

私が見たいくつかのプロジェクトは、コマンドラインツールをコマンドオブジェクトとして実装しています（例：Rubygemsと私の改行gem）。これらのオブジェクトはARGVで初期化され、プロセス全体を開始する呼び出しまたは実行メソッドがあります。これにより、これらのプロジェクトはコマンドラインアプリケーションを仮想環境に配置できます。たとえば、コマンドオブジェクトのインスタンス変数に入力ストリームオブジェクトと出力ストリームオブジェクトを保持して、アプリケーションをSTDOUT/STDINの使用に依存しないようにすることができます。したがって、コマンドラインアプリケーションの入力/出力をテストすることが可能になります。私が想像するのと同じように、現在の作業ディレクトリをインスタンス変数に保持して、コマンドラインアプリケーションを実際の作業ディレクトリから独立させることができます。次に、テストごとに一時ディレクトリを作成し、これをCommandオブジェクトの作業ディレクトリとして設定できます。

そして今、いくつかのコード：

require 'pathname'

class MyCommand
  attr_accessor :input, :output, :error, :working_dir

  def initialize(options = {})
    @input = options[:input] ? options[:input] : STDIN
    @output = options[:output] ? options[:output] : STDOUT
    @error = options[:error] ? options[:error] : STDERR
    @working_dir = options[:working_dir] ? Pathname.new(options[:working_dir]) : Pathname.pwd
  end

  # Override the puts method to use the specified output stream
  def puts(output = nil)
    @output.puts(output)
  end

  def execute(arguments = ARGV)
    # Change to the given working directory
    Dir.chdir(working_dir) do
      # Analyze the arguments
      if arguments[0] == '--readfile'
        posts_dir = Pathname.new('posts')
        my_file = posts_dir + 'myfile'
        puts my_file.read
      end
    end
  end
end

# Start the command without mockups if the ruby script is called directly
if __FILE__ == $PROGRAM_NAME
  MyCommand.new.execute
end

これで、テストのセットアップと分解の方法で次のことができます。

require 'pathname'
require 'tmpdir'
require 'stringio'

def setup
  @working_dir = Pathname.new(Dir.mktmpdir('mycommand'))
  @output = StringIO.new
  @error = StringIO.new

  @command = MyCommand.new(:working_dir => @working_dir, :output => @output, :error => @error)
end

def test_some_stuff
  @command.execute(['--readfile'])

  # ...
end

def teardown
  @working_dir.rmtree
end

（この例では、Rubyの標準ライブラリからの非常に優れたオブジェクト指向ファイルシステムAPIであるPathnameと、単純な文字列にストリーミングされるIOオブジェクトであるためSTDOUTのモックに役立つStringIOを使用しています）

実際のテストでは、@ working_dir変数を使用して、ファイルの存在または内容をテストできるようになりました。

path = @working_dir + 'posts' + 'myfile'
path.exist?
path.file?
path.directory?
path.read == "abc\n"
于 2011-02-19T20:06:07.930 に答える
1

私の経験から（したがって、これは非常に主観的です）、テストが難しい一部の領域でユニットテストをスキップしても問題ない場合があると思います。あなたはあなたが見返りに何を得るか、そしてテストのためのコストを見つける必要があります。私の親指のルールは、クラスをテストしないという決定は非常に珍しいはずです（300クラスに1つ未満）

ファイルシステムとの依存関係のために、テストしようとしていることが非常に難しい場合は、ファイルシステムと相互作用するすべてのビットを抽出することを試みることができると思います。

于 2011-02-19T19:06:12.157 に答える