2011-06-30 11 views
42

Mam aplikację, która korzysta z subdomen do przełączania baz danych (multi-tenancy). Próbuję użyć Capybary do testowania integracji i naprawdę bardzo zależy od subdomen.Kapibara z subdomenami - default_host

Rozumiem, że ustawienie Capybara.default_host= na coś spowoduje, że wszystkie moje żądania będą pochodzić od tego hosta. Wydaje się, że tak nie jest. W dokumencie this post autor zaleca odwiedzenie jawnego adresu URL z hostem, ale staje się to nieco denerwujące, gdy nawiguję w dowolnym miejscu. Chciałbym ustawić hosta, a następnie móc korzystać z moich ścieżek rails zgodnie z oczekiwaniami. Nie wiem, co robię źle, ale oto co próbowałem:

# spec_helper.rb 
RSpec.configure do |config| 
    config.before(:each, :type => :request) do 
    Capybara.default_host = 'http://app.mydomain.com' 
    end 
end 

# in some_integration_spec.rb 
before do 
    puts "Capybara.default_host: #{Capybara.default_host}" 
    puts "some_app_url: #{some_app_url}" 
end 

Daje wyjście:

Capybara.default_host: http://app.mydomain.com 
some_app_url: http://www.example.com/some_path 

Co robię źle? default_host wydaje się nic nie robić. Jak już mówiłem, nie chcę mówić: visit(Capybara.default_host + some_app_path), ponieważ za każdym razem jest to trochę denerwujące. Dlaczego jeszcze istnieje ta opcja default_host?

+0

Może być pomocny dla kogoś [moja odpowiedź to pytanie] (http://stackoverflow.com/a/18476731/895789) –

Odpowiedz

56

Nie jestem pewien co do zamierzonego zastosowania default_host, ale app_host robi to, czego potrzebujesz. Odkryłem, że najpierw muszę wywołać metodę sesji railsowej host!, aby ustawić ciąg hosta, który zostanie przekazany kontrolerom w obiekcie żądania.

Następnie należy ustawić Capybara.app_host, aby poinformować Capybara, aby zadzwoniła do Twojej aplikacji za pośrednictwem serwera WWW, a nie po prostu nawiązywała połączenia. Jeśli tego nie zrobisz, Capybara wykaże się, gdy napotka przekierowania i upuści informacje o hoście w drugim żądaniu.

Nie jestem pewien, dlaczego to nie zajmuje się automatycznie końcowymi sprawami Railsów request, ale odkryłem, że jeśli nie ustawię hosta w obu miejscach, otrzymam niespójne wyniki.

def set_host (host) 
    host! host 
    Capybara.app_host = "http://" + host 
end 

before(:each) do 
    set_host "lvh.me:3000" 
end 

Następnie można po prostu użyć względnych ścieżek dostępu do stron.

Aktualizacja:

Kapibara 2.x i rspec barierki 2.12.0 wprowadzone "funkcji" specyfikacje dotyczące prowadzenia testów akceptacyjnych kapibary. Nowy moduł w rspec-rails jest inny niż RequestExampleGroup i nie ma już dostępu do metody testowania stelaża host!. Teraz chcesz użyć default_url_options zamiast:

def set_host (host) 
    # host! host 
    default_url_options[:host] = host 
    Capybara.app_host = "http://" + host 
end 
+0

interesujące ... przyjrzę się temu, gdy dostanę szansę. dzięki! – brad

+0

wygląda jak app_host jest zwycięzcą, chciałbym, aby doktorzy byli bardziej jasne co do różnicy, dzięki! – brad

+4

To działa idealnie. Ponadto, jeśli używasz domeny publicznej, takiej jak 'lvh.me', możesz ustawić port automatycznie za pomocą' Capybara.server_port = 31234', a następnie 'set_host" lvh.me:31234 "' – alf

0

To nie jest dokładnie taka sama sytuacja ponieważ może to pomóc niektórym osobom:

W przypadku mojego obecnego projektu używam pow z wieloma subdomenami. Zestaw testów musi również działać na innym porcie.

Rozwiązanie zależy od używanej wersji kapibara.

W bieżącym najnowszym wydaniu Ja to w custom_env.rb:

Capybara.server_host = 'myapp.dev' 
Capybara.server_port = 9887 
Capybara.run_server = true 

# I don't remember what this was for. Another team member wrote this part... 
module ActionDispatch 
    module Integration #:nodoc: 
    class Session 
     def host 
     [Capybara.server_host, Capybara.server_port].join(':') 
     end 
    end 
    end 
end 

Z kapibary 1.1.2, miałem zrobić Powyższa zmiana ale server_host staje app_host i modyfikować lib/kapibary/serwer. rb w gem jak poniżej:

def url(path) 
    .. 
    if path =~ /^http/ 
    path 
    else 
    # Was this (Capybara.app_host || "http://#{host}:#{port}") + path.to_s 
    (Capybara.app_host || "http://#{host}") + ":#{port}" + path.to_s 
    end 
end 
29

Kiedy trzeba zmienić adres URL zawierać subdomenę, można określić app_host w definicjach kroku. Użyj domenę jak lvh.me ponieważ wskazuje 127.0.0.1:

Capybara.app_host = "http://#{subdomain}.lvh.me" 

Kapibara zakłada, że ​​kiedy jesteś określając app_host że jesteś testowania zdalnego serwera działa na porcie 80, ale w naszym przypadku Testujemy lokalna aplikacja działająca na losowym porcie określonym przez Capybara. Aby rozwiązać ten problem, w pliku env.rb, dodaj linię:

Capybara.always_include_port = true 

Teraz, gdy użytkownik odwiedza stronę aplikacji ...

visit '/page' 

... url będzie określać również subdomenę jako port, na którym działa aplikacja.

FYI: To zadziałało dla mnie przy użyciu Capibara 2.0.2.

+2

Ta metoda działa również dla mnie i żadna z innych metod nie działa. Jestem na Kapibarze 2.4.3. Dla mojej aplikacji chcę również znać numer portu wybrany przez Capybara z mojego środowiska testowego. Używam Poltergeist/PhantomJS i mogę uzyskać te informacje z tego połączenia: '' 'Capybara.current_session.server.port''' –

0

dzień:

  • kapibary (2.4.1)
  • kapibary-WebKit (1.3.0)

    Capybara.server_host = "example.com" 
    Capybara.server_port = 3050 
    Capybara.run_server = true 
    Capybara.javascript_driver = :webkit #requires capybara-webkit 
    
+0

To wydaje się być błędem, ponieważ najnowsza wersja kapibary to 2.13.0 . – Siraris

Powiązane problemy