Pregunta

he estado tratando de resolver un problema para algunas semanas. Me postulo pruebas rspec para mi aplicación Rails, y están trabajando bien, excepto por un error que parece que no puedo sacarlo de mi cabeza.

  • Estoy utilizando MySQL con el motor InnoDB.
  • he puesto en config.use_transactional_fixtures = true spec_helper.rb
  • cargo mis accesorios de prueba manualmente con el comando rake spec:db:fixtures:load.
  • La prueba rspec está siendo escrito para un trabajador BackgrounDRb, y se está probando que puede haber un registro actualizado su estado (a través de la gema state_machine).

Aquí está mi problema:

Tengo un modelo llamado Listings. La prueba rspec llama al método update_sold_items dentro de un archivo llamado listing_worker.rb. Este método llama listing.sell para un registro determinado, que establece el récord lista de 'estado' a la columna 'vendido'. Hasta ahora, todo esto está bien de trabajo, pero cuando los acabados método update_sold_items, mi prueba rspec falla aquí:

listing = Listing.find_by_listing_id(listing_id)
listing.state.should == "sold"

expected: "sold",
     got: "current" (using ==)

he estado tratando de localizar a por qué el cambio de estado no está persistiendo, pero estoy bastante perdido. Este es el resultado de un cierto código de depuración que coloqué en el método update_sold_items durante la prueba:

pp listing.state  # => "current"

listing.sell!
listing.save!

pp listing.state  # => "sold"

listing.reload

pp listing.state  # => "current"

No se puede entender por qué se ahorra perfectamente bien, pero luego vuelve de nuevo al registro original siempre que llame reload o Listing.find etc.

Gracias por leer esto, y por favor cualquier pregunta si no he dado suficiente información.

Gracias por su ayuda, Nathan B

P.S. No tengo un problema al crear nuevos registros para otras clases, y los ensayos de los registros. Sólo parece ser un problema cuando estoy actualizando los registros que ya existen en la base de datos.

¿Fue útil?

Solución

sospecho, como Nathan, ediciones de la transacción. Trate de poner un Listing.connection.execute ( "COMMIT") justo antes de su primer salvamento llamada a romper la transacción y ver qué cambios. Que se romperá a salir de la transacción para cualquier llamada de reversión adicionales serán no eficaz.

Además, mediante la ejecución de un comando "COMMIT", se podría hacer una pausa en la prueba con un depurador e inspeccionar la base de datos de otro cliente para ver lo que está pasando.

La otra hipótesis, si la experimentación transacción no dió ningún resultado, es que tal vez su modelo realmente no está ahorrando a la base de datos. Revisar sus registros de consultas. (Específicamente encontrar la consulta de actualización).

Este tipo de cuestiones realmente apesta! ¡Buena suerte!

Otros consejos

Si desea investigar lo que tiene en el PP durante la ejecución de pruebas que puede encontrar útil esta información ...

Tengo una prueba rspec donde guardar @ user.save y funciona como un encanto, pero entonces yo quería ver si realmente guarda en la base de datos.

Me abrió la consola carriles para el entorno de prueba

rails c test

RAN

User.all

y como se esperaba nada tiene

Me pasé la especificación que contiene:

user_attr_hash    = FactoryGirl.attributes_for(:user)
@user = User.new user_attr_hash
@user.save
binding.pry

pensé que detener la prueba después de guardar significaría que se persistió, pero ese no es el caso. Parece que el COMMIT se dispara la conexión más tarde (no tengo ni idea cuando: \) Por lo tanto, como sugiere @Tim Harper, usted tiene que fuego que cometen a sí mismo en la consola de palanca:

pry(#<RSpec::Core::ExampleGroup::Nested_1>)> User.connection.execute("COMMIT")

Ahora, si ejecuta User.all en sus rieles consola que merece la pena verlo;)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top