0

Railsモデルの1つをテストしていますが、システムのRubyがクラッシュし続けますか? これは以前にも Growl で発生しましたが、System の ruby​​ では発生しませんでした。すでに再起動しましたが、まだ発生しています。を使用Ruby-1.9.3-p194していますが、 で同じクラッシュが発生しruby-1.9.3-p0ます。私の仕様は無害に思えますが、なぜこれが起こっているのかわかりません。

仕様:

インデントでごめんなさい。

「spec_helper」が必要

describe "Admin pages" do
  subject { page}

  describe "when not signed in" do
    before { visit admin_path }
    it { should have_selector('title', text: 'Sign in') }
end

describe "when signed in as an admin" do
before do 
  sign_in 
  visit admin_path
end

describe "Admin navigation menu" do
  it { should have_css('.nav-header', text: 'Content') }
  it { should have_link('Dashboard',  href: admin_path) }
  it { should have_link('News',       href: admin_posts_path) }
  it { should have_link('Events',     href: admin_events_path) }
  it { should have_link('Photos',     href: admin_photos_path) }
  it { should have_css('.nav-header', text: 'Your Account') }
  it { should have_link('Settings',   href: admin_settings_path) }
  it { should have_link('Help',       href: admin_help_path) }

  describe "should be on every admin page" do
    after { should have_admin_navigation }
    it { visit admin_path }
    it { visit admin_posts_path }
    it { visit admin_photos_path }
    it { visit admin_settings_path }
  end


  describe "should not be on any other pages" do
    before { visit root_path }
    it { should_not have_css('#admin-navigation') }
  end

end

describe "Dashboard (index) page" do
  before { visit admin_path }
  it { should have_selector('h3', text: 'Dashboard') }
  it { should have_selector('title', text: full_title('Admin Dashboard')) }
end

describe "Posts page" do
  before { visit admin_posts_path }
  it { should have_selector('h3', text: 'Posts') }
  it { should have_selector('table') }
  it { should have_selector('th', text: 'Title') }
  it { should have_selector('th', text: 'Content') }
  it { should have_selector('th', text: 'Published On') }
end

describe "Events page" do
  before { visit admin_events_path }
  it { should have_selector('h3', text: 'Events') }
  it { should have_selector('input') }
end

end
end

フォーマットを保持する要点としてのシステム クラッシュ レポート。

編集：コメントして絞り込みましたが、エラーは@second_pageのファクトリーと関係があります。

4

1 に答える 1

1

これを支援するデバッグツールがあります。rubyのトレースを使用して、すべてのメソッド呼び出しをログに記録します。最後の呼び出しは、クラッシュする前に実行する最後の呼び出しである必要があります。たぶん、これを実行して、クラッシュ前の最後のメソッド呼び出しが何であったかを確認し、それが一貫しているかどうかを確認してみてください。参考までに、この実装はアプリの速度を大幅に低下させますが、ピンチで良い情報を得ることができます。

https://github.com/ericbeland/debugtools/blob/master/tracing.rb

メソッド呼び出しを知ったら、誰が/何が責任を負っているのかがわかるといいのですが。

-------手順で編集-----------

リンクされたファイルをダウンロードします（または空のファイルに貼り付けます）。アプリ内で、ファイルが必要です。次に、application.rb内で次の手順を実行します。

 include Tracing

 class Object
  include Tracing
 end

コード内で可能な限り遅い場所を見つけます。これまで、コードがクラッシュするのを見たことがない最後のポイントです。したがって、新しい編集に基づいて、そのテストの開始時に。その時点で、次のステートメントを貼り付けます。

 tracing_on('/tmp/tracelog.txt')

これにより、ロギングが開始されます。クラッシュするまで物事を実行させます。その時点で、/ tmp / tracelog.txtを調べて、どこで死んだかを確認します。

于 2012-07-31T22:08:11.503 に答える