not javascript ruby-on-rails-3 capybara

javascript - referenceerror function is not defined



Carpincho con: js=> prueba de causa verdadera falla (3)

Hay otra manera de lidiar con este problema ahora descrito y discutido aquí: ¿Por qué no usar conexiones ActiveRecord compartidas para Rspec + Selenium?

Soy nuevo en Capybara y estoy probando en Rails en general, así que por favor, perdónenme si esta es una respuesta simple.

Tengo esta prueba

it "should be able to edit an assignment" do visit dashboard_path select(@project.client + " - " + @project.name, :from => "assignment_project_id") select(@team_member.first_name + " " + @team_member.last_name, :from => "assignment_person_id") click_button "Create assignment" page.should have_content(@team_member.first_name) end

pasa como está, pero si agrego: js => true falla con

cannot select option, no option with text ''Test client - Test project'' in select box ''assignment_project_id''

Estoy usando FactoryGirl para crear los datos, y como la prueba pasa sin JS, sé que esa parte está funcionando.

Lo he intentado con el controlador JS predeterminado y con el controlador: webkit (con capybara-webkit instalado)

Creo que no entiendo lo que está haciendo encender JS para Capibara.

¿Por qué fallaría la prueba con JS activado?


Leí el archivo léxico de Capybara en https://github.com/jnicklas/capybara y resolvió mi problema.

Los dispositivos transaccionales solo funcionan en el controlador Rack :: Test predeterminado, pero no para otros controladores como Selenium. Cucumber se encarga de esto automáticamente, pero con Test :: Unit o RSpec, es posible que tengas que utilizar la gema database_cleaner. Vea esta explicación (y el código para la solución 2 y la solución 3 ) para más detalles.

Pero básicamente es un problema de subprocesamiento que implica que Capybara tiene su propio hilo cuando ejecuta el controlador que no es de Rack, que hace que la característica de dispositivos transaccionales use una segunda conexión en otro contexto. Entonces, el hilo del controlador nunca está en el mismo contexto de la ejecución de rspec.

Afortunadamente, esto se puede resolver fácilmente (al menos se resolvió para mí) haciendo un cambio dinámico en la estrategia de DatabaseCleaner para usar:

RSpec.configure do |config| config.use_transactional_fixtures = false config.before :each do if Capybara.current_driver == :rack_test DatabaseCleaner.strategy = :transaction else DatabaseCleaner.strategy = :truncation end DatabaseCleaner.start end config.after do DatabaseCleaner.clean end end


Una variación de la respuesta de brutuscat que corrigió nuestras características (que usan Capibara):

config.before(:suite) do DatabaseCleaner.clean_with(:truncation) end config.before(:each) do # set the default DatabaseCleaner.strategy = :transaction end config.before(:each, type: :feature) do DatabaseCleaner.strategy = :truncation end config.before(:each) do DatabaseCleaner.start end config.append_after(:each) do DatabaseCleaner.clean end