0

私はRailsアプリで面白いことをしています。別のDBに接続して情報を読み取りますが、書き込みはしません。これらの接続を簡単にするために、テーブルを処理するモデルを作成しました。私は2つの同様のクラスを持っているので、要点を理解するために1つを次に示します。

# call.rb
class Call < ActiveRecord::Base
  # We don't want to change these values in the table, only read them
  attr_reader :uniqueid, :queue, :agent_id, :codes, :code_count

  def self.connect
    establish_connection "ihs"
    self.table_name = 'calls'
  end

  def self.disconnect
    self.connection.close
  end
end

この接続が Rails アプリの DB へのメイン接続をオーバーライドすることは望ましくありません。これは一時的なものです。ここで、これらのメソッドを呼び出すたびに、これらの接続が実際に確立され、閉じられることをテストしたいと思います。現時点で、私が考えたのは次のとおりです。

# call_spec.rb
describe Call do

  [code omitted]

  describe "#connect" do
    # before { Call.disconnect }

    it "establishes a connection to IHS DB" do
      puts Call.count
      lambda { Call.count }.should raise_error(ActiveRecord::StatementInvalid)
      Call.connect
      lambda { Call.count }.should_not raise_error
    end
  end
end

スローされた例外のタイプを確認するためにを使用してこのコードをテストしましたbegin ... rescue Exception => e; puts e.class; endが、実際には ActiveRecord::StatementInvalid 例外ですが、このテストはパスしません。私がスローされているエラーは次のとおりです。

Failure/Error: puts Call.count
  ActiveRecord::StatementInvalid:
    PG::Error: ERROR:  relation "calls" does not exist
      [rest omitted]

これは私が期待しているエラーです。合格するためにテストを微調整する方法がわかりません。任意のヒント？

4

2 に答える 2

0

への呼びかけ

puts Call.count

実際の例外の直前に、rspec が「キャッチ」する前にエラーが発生しています。

于 2013-03-28T16:16:01.347 に答える
0

明示的に接続および切断することがなぜ重要なのだろうか? セカンダリ データベースに接続して読み取りたい 1 つのアプリでは、次のような接続を処理する基本クラスからすべてのアクティブ レコード クラスを継承します。

class IhsActiveRecord < ActiveRecord::Base
  self.abstract_class = true
  establish_connection "#{Rails.env}_ihs"
end

こうすることで、再接続と切断を頻繁に行う必要がなくなり、接続ロジックを 1 か所に保つことができます。実際の接続情報は、引き続き database.yml ファイルに入れることができます。上記では、環境ごとに個別のものを用意しています。database.yml と一致する限り、調整できます。

また、仕様でラムダの代わりに expect {} を使用することをお勧めします。

于 2013-03-28T16:17:26.357 に答える