2011-09-06 12 views
9

Uso le rotaie solari per la ricerca. Si tratta di un aspetto Rspec:connessione rifiutata da solr in Rspec

describe "GET search" do 
    before(:all) do 
    system("rake", "sunspot:solr:start") 
    end 

    after(:all) do 
    system("rake", "sunspot:solr:stop") 
    end 

    it "should do some search" do 
    Text.search do 
     ... 
    end 
    end 
end 

Ma non funziona. Ho avuto un fallimento:

Errno::ECONNREFUSED: 
    Connection refused - connect(2) 

Ma se digito rake sunspot:solr:start RAILS_ENV=test a mano in linea di comando, e quindi eseguire le specifiche, passa.

Cosa c'è che non va? Non è rake sunspot:solr:start RAILS_ENV=test equivalente a system("rake", "sunspot:solr:start") in modalità test?

(ho provato `sistema ("rake", "macchie solari: solr: iniziare RAILS_EVN = test") Stesso..)

risposta

14

Il tuo before(:all) probabilmente non sta dando a Solr abbastanza tempo per iniziare.

Detto questo, probabilmente vorrai riflettere su quello che stai chiedendo alle tue specifiche per verificare qui. Puoi fare una lunga strada con le chiamate a Solr con una biblioteca come Fakeweb.

Pivotal Labs ha anche una libreria chiamata sunspot_matchers in grado di catturare le affermazioni più capillare circa le ricerche si sta invocando.

Se si sta utilizzando specifiche di integrazione reali contro Solr, si consiglia di tenere in esecuzione un Solr di test mentre si lavora. Uno strumento come Foreman può aiutare a gestire i tuoi processi Solr. Potrei usare un Procfile come la seguente:

solr_dev: rake sunspot:solr:run RAILS_ENV=development 
solr_test: rake sunspot:solr:run RAILS_ENV=test 

(Sviluppo è, naturalmente, l'ambiente predefinito se nessun RAILS_ENV diverse disposizioni a foreman start)

Infine, se si desidera avviare Solr all'interno delle vostre specifiche , sei già sulla buona strada. Basta lanciare un sleep lì dentro con un tempo sufficiente per permettere a Solr di avviarsi completamente prima che le specifiche inizino a girare. Non sorprenderti se questo introduce un po 'di errore imprevedibile nella tua suite spec quando il sistema è sotto carico.

[Edit:. Rapido e sporco before :all che utilizza Sunspot.remove_all polling la disponibilità]

before :all do 
    `sunspot-solr start` 
    begin 
    Sunspot.remove_all! 
    rescue Errno::ECONNREFUSED 
    sleep 1 && retry 
    end 
end 
+0

grazie. A proposito, come posso sapere se solr è in esecuzione nella mia specifica? Voglio un'eccezione personalizzata più corretta invece di "connessione rifiutata" –

+0

Penso che "Errno :: ECONNREFUSED" sia piuttosto indicativo. In effetti, è possibile utilizzarlo per sondare la disponibilità. L'ho appena violato in una modifica. –

+0

ottima soluzione. ha funzionato come un sogno per me. – nfriend21

0

Questo è un ipotesi-ass, ma scommetto che avete un server Solr configurato nel vostro config/ambienti/development.rb file da guardare localmente su una determinata porta, ma nessuna tale configurazione nel proprio config/ambienti/test.rb

Questo sta causando di connettersi all'indirizzo di difetto/porta in cui in effetti non si dispone di un server Solr in esecuzione quando si eseguono i test.

Non so abbastanza del client Solr in Ruby per essere sicuro di questo, ma poiché nessun altro ha pesato in ancora spero che questo ti punti nella giusta direzione.

11

Il sunspot_test gem farà questo per voi e supporta RSpec.

+0

Impressionante, questa è sicuramente la risposta giusta! – Matthew

+0

Sicuramente una risposta elegante e un gioiello - grazie. –

0

ho ottenuto questo lavoro solo con l'aggiunta

`rake sunspot:solr:start RAILS_ENV=test` 

a spec_helper.rb

Edit: ho finito per andare con https://github.com/collectiveidea/sunspot_test come Simmo menzionato. Stava eseguendo di nuovo il task rake su ogni test eseguito per qualche motivo (anche se l'ho avuto nel blocco di prefork di spork). Non so perché, ma la gemma sunspot_test sembra la strada da fare per ora.

+0

Funziona per te su Rails 3.1? –

Problemi correlati